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Software  and  System  Warranty  Issues  and  Generic 
Warranty  Clause 

Abstract:  This  report  describes  how  to  effectively  include  software  issues  into 
a  system  warranty.  The  report  includes  a  generic  system  warranty  clause, 
witt)  a  description  of  the  rationale  for  each  paragraph  in  the  clause.  The 
clause  will  have  to  be  tailored  to  the  circumstances  of  the  system,  and  some 
tailoring  considerations  are  described.  There  is  also  a  description  of  the  im¬ 
portant  legal,  technical,  and  administrative  concerns  which  are  directly  related 
to  the  warranty  issues.  The  report  describes  the  need  for  such  a  systems  war¬ 
ranty,  and  includes  firm  recommendations  on  how  to  use  such  a  warranty  to 
Improve  the  quality  of  the  delivered  system.  ^ - 


1.  Executive  Summary 

Task  Description 

The  Software  Engineering  Institute  was  asked  by  the  Department  of  Defense  to  recom¬ 
mend  a  "clear,  enforceable  software  warranty  dause(s)  that  can  be  integrated  into  . . . 
system  warranties."  The  clause  was  to  be  "concise  (one  to  two  pages)  and 
understandable."  In  response  to  that  request,  we  have  drafted  a  straight-forward  two- 
page  generic  system  warranty  clause  that  covers  software,  not  in  isolation,  but  as  part  of 
a  warranted  system. 

At  first,  our  task  appeared  to  be  strictly  a  legal  exercise.  On  investigating  the  motivation 
for  the  task,  however,  it  became  clear  that  a  software  warranty  clause  alone  would  not 
solve  the  basic  problems  that  led  to  the  task  in  the  first  plaoe.  The  Software  Engineering 
Institute  (SEI)  discovered  that  the  enforcement  problem  was  not  so  much  associated 
with  the  legal  framework  of  various  warranty  clauses,  but  with  the  lack  of  meaningful 
specifications  and  tests  designed  to  demonstrate  system  defects  that  trigger  warranty 
coverage  of  the  system  as  a  whole.  The  scope  of  the  task  was  therefore  broadened  to 
address  technical  and  administrative  issues  associated  with  the  system  warranty  proc- 


Those  issues  are  fundamental  to  the  generic  clause  we  have  developed.  Chapters  3 
through  9  of  this  report  therefore,  outline  the  legal,  technical,  and  administrative  issues 
associated  with  the  application  and  enforcement  of  an  inclusive  system  warranty.  The 
clause,  and  a  paragraph  by  paragraph  explanation  of  its  provisions,  are  found  in  Chap¬ 
ters  10  and  1 1  of  this  report. 
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Approach 

Our  understanding  is  that  recent  experiences  with  deployed  systems  have  revealed 
problems,  and  existing  warranties  have  not  been  an  effective  remedy  to  those  problems. 
The  crux  of  the  matter  is  twofold: 

1.  The  deployed  systems  do  not  meet  user  requirements  and  have  unaccept¬ 
able  failure  rates. 

2.  Often  the  failures  appear  to  be  associated  with  software,  but  existing  war¬ 
ranties  have  not  generally  provided  an  adequate  remedy  for  such  failures. 

We  believe  these  warranty-related  problems  have  two  causes: 

1. The  burden  of  proving  not  only  the  existence  of  a  defect,  but  also  the 
contractor’s  responsibility  for  that  defect,  ordinarily  falls  on  the  govern¬ 
ment. 

2.  Existing  warranties  frequently  have  not  defined  defects  in  terms  of  ade¬ 
quately  verifiable  specifications  and  tests  that  would  permit  the  govern¬ 
ment  to  demonstrate  a  breach  of  warranty  in  satisfaction  of  its  burden  of 
proof. 

Although  there  are  several  possible  remedies  to  problems  of  system  failure,  in  conform¬ 
ity  with  the  SEI’s  assigned  task,  this  report  describes  one  approach  to  relieving  these 
problems:  write  a  more  enforceable  system  warranty  clause,  and  address  the  legal, 
technical,  and  administrative  issues  that  support  warranty  enforcement  The  goal  is  to 
ease  the  government's  burden  of  proving  the  existence  of  a  defect  for  which  the  war¬ 
ranty  clause  provides  a  remedy.  The  key  to  satisfying  that  goal  is  to  develop  technical 
tests  and  specifications  that  provide  objective  and  demonstrable  standards  against 
which  a  claim  for  breach  of  warranty  can  be  measured. 

Recommendations 

The  following  recommendations  are  derived  from  the  report: 

1.  To  ease  the  burden  the  government  bears  to  prove  a  breach  of  warranty, 
the  generic  warranty  should  cover  the  failure  of  a  delivered  system  as  a 
whole,  including,  but  not  limited  to,  its  software,  to  satisfy  clear  and  meas¬ 
urable  essential  performance  requirements  for  the  system.  Essential  per¬ 
formance  requirements  must  be  based  on  a  dear  distinction  between  the 
warranted  product  and  other  components  in  the  environment. 

2.  Conditions  for  establishing  breach  of  warranty  should  be  described  in 
terms  of  analysis  of  recorded  symptoms  and  diagnostic  results.  The  test 
methods  to  determine  breach  should  be  described  in  the  specifications. 

3.  Through  careful  drafting  and  aggressive  litigation  techniques,  the  govern¬ 
ment  has  a  good  chance  of  changing  the  currently  accepted  legal  stan¬ 
dard,  and  of  shifting  to  the  contractor  the  burden  of  proving  that  system 
defects  are  attributable  to  government-furnished  equipment.  Even  if  the 
burden  cannot  be  shifted,  however,  the  government's  burden  of  proof  can 
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be  minimized  by  developing  tests  and  procedures  that  will  isolate  defects 
in  government-furnished  equipment. 

4.  To  provide  maximum  applicability  and  enforceability,  the  generic  clause 
should  be  modeled  after  the  Weapon  Systems  Warranty  Act,  and  must  be 
carefully  tailored  on  a  case  by  case  basis. 

5.  Government  procurement  practices  contribute  substantially  toward  existing 
problems.  If  it  is  to  reap  the  benefit  of  improved  legal  and  technical  war¬ 
ranty  considerations,  the  government  must  improve  such  practices. 

6.  The  quality  of  the  product  is  heavily  dependent  on  the  specifications  de¬ 
scribing  the  product  and  the  clear  description  of  the  critical  functions  to  be 
performed.  The  success  of  a  product  and  the  applicability  of  a  warranty 
depend  on  a  well  crafted  specification. 

7.  Warranties  are  not  costless,  and  contractors  can  be  expected  to  price  war¬ 
ranties  even  higher  as  their  exposure  to  warranty  liability  Increases 
through  increased  warranty  scope,  remedies,  and  enforceability.  There 
are  remedies  other  than  warranties  which  also  would  improve  the  de¬ 
ployed  products,  so,  in  each  individual  case,  the  costs  and  benefits  of  the 
warranty  must  be  balanced  against  the  costs  and  benefits  of  other  ap¬ 
plicable  remedies. 
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2.  Introduction 


Deployed  military  systems  involve  a  mixture  of  computer  software,  hardware,  and  asso¬ 
ciated  other  equipment,  operating  In  unison  with  operational  personnel,  to  provide  func¬ 
tions  vital  to  national  security.  Recent  experiences  with  deployed  systems  have 
revealed  problems,  and  existing  warranties  have  not  been  an  effective  remedy  to  those 
problems.  The  crux  of  the  matter  is  twofold: 

1 .  The  deployed  systems  do  not  meet  user  requirements  and  have  unaccept¬ 
able  failure  rates. 

2.  Often  the  failures  appear  to  be  associated  with  software,  but  existing  war¬ 
ranties  have  not  generally  provided  an  adequate  remedy  tor  such  failures. 

We  believe  these  warranty-related  problems  have  two  causes: 

1. The  burden  of  proving  not  only  the  existence  of  a  defect,  but  also  the 
contractor's  responsibility  for  that  defect,  ordinarily  falls  on  the  govern¬ 
ment. 

2.  Existing  warranties  frequently  have  not  defined  defects  in  terms  of  ade¬ 
quately  verifiable  specifications  and  tests  that  would  permit  the  govern¬ 
ment  to  demonstrate  a  breach  of  warranty  In  satisfaction  of  its  burden  of 
proof. 

In  response  to  these  problems,  the  SEI  was  asked  to  write  a  concise  (no  more  than 
two-page)  and  enforceable  software  warranty  clause.  We  note  here,  however,  that  there 
are  other  possible  remedies  to  current  system  acquisition  problems  that  should  also  be 
considered  in  each  individual  case  —  contractors  can  be  expected  to  include  their  an¬ 
ticipated  costs  of  providing  warranty  protection  in  the  acquisition  costs,  and  those  addi¬ 
tional  costs  may  at  some  point  outweigh  the  incremental  benefits  the  warranty  provides. 
This  report  describes  one  approach  to  relieving  system  performance  problems  in  future 
acquisitions:  Write  a  more  enforceable  warranty,  and  address  the  legal,  technical,  and 
administrative  issues  that  support  warranty  enforcement  The  goal  is  to  ease  the 
government's  burden  of  proving  the  existence  of  a  defect  for  which  the  warranty  clause 
provides  a  remedy. 

At  first  this  task  appeared  to  be  strictly  a  legal  exercise,  but  on  investigating  the  motiva¬ 
tion  for  the  task,  it  became  dear  that  a  software  warranty  clause  alone  would  not  solve 
the  basic  problems.  The  scope  of  the  task  was  therefore  broadened  to  address  tech¬ 
nical  and  administrative  issues  associated  with  the  system  warranty  process.  After 
meeting  with  Department  of  Defense  (DoD)  personnel,  we  decided  to  look  more  closely 
Into  the  problems  associated  with  a  specific  system  illustrating  the  problem.  We  chose 
to  concentrate  on  the  FPS-117  Seek  Igloo  radar,  since  it  is  deployed  and  applicable 
failure  data  are  available.  We  had  hoped  that  an  analysis  of  the  failure  conditions  and 
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corrections  would  provide  information  which  we  could  then  extract  and  apply  directly 
toward  the  warranty  specifications.  Unfortunately,  the  failure  reports  on  this  project  were 
not  sufficiently  detailed  to  support  a  meaningful  analysis.  Nevertheless,  evaluation  of 
the  FPS-1 17  radar  specification  and  summary  failure  data  provided  valuable  insight. 

This  report  outlines  the  issues  associated  with  the  application  of  a  product  warranty.  In 
Chapters  3  through  9,  we  describe  the  context  in  which  the  problem  arises,  and  then  we 
describe  legal,  technical,  and  administrative  issues  involved  in  developing  a  system  war¬ 
ranty.  Chapter  10  contains  the  two-page  generic  system  warranty  clause  that  was 
originally  requested.  The  warranty  clause  is  based  on  the  Issues  and  considerations 
outlined  in  the  earlier  chapters  of  this  report.  A  paragraph  by  paragraph  explanation  of 
the  clause  appears  in  Chapter  1 1 . 
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3.  Context 


Any  discussion  of  warranty  needs  to  consider  the  question,  To  what  does  the  warranty 
apply?"  in  the  context  of  systems  acquisition,  the  simplest  answer  is:  The  warranty 
applies  to  a  product  produced  by  a  contractor.  Practically  speaking,  a  contractor  can 
warrant  nothing  else.  A  warranty  is  a  statement  made  by  a  contractor  about  the  nature, 
usefulness,  or  condition  of  a  product,  and  the  contractor's  intention  to  stand  behind 
those  statements  under  stated  terms  and  conditions.  See  FAR  (Federal  Acquisition 
Regulations)  Section  46.701 . 

Where  systems  employ  computers,  a  product  is  often  considered  to  be  composed  of 
hardware  or  software,  or  some  combination  of  both.  But  thinking  of  a  product  in  terms  of 
its  components  often  causes  confusion  and  detracts  from  the  main  intent  of  a  warranty: 
to  encourage  the  contractor  to  produce  and  be  accountable  for  a  finished  product  that 
meets  the  needs  of  the  intended  mission.  To  satisfy  that  Intent,  a  warranty  should  be 
neither  a  hardware  nor  a  software  warranty.  Rather,  a  warranty  should  be  a  product 
warranty  and  should  cover  what  the  contractor  produces,  regardless  of  the  particular  ele¬ 
ments  making  up  the  product.  This  approach  also  best  addresses  the  legal  issues  re¬ 
specting  burden  of  proof,  issues  to  which  we  now  turn. 

A  product  consists  of  various  types  of  deliverables  besides  the  hardware  and  executing 
code.  Included  within  the  scope  of  the  product  are  source  code,  test  harnesses,  ex¬ 
ecutable  code,  persistent  data  objects,  and  documentation.  The  warranty  issues  de¬ 
scribed  throughout  this  document  relate  mostly  to  the  hardware  and  executable  code  in 
the  operational  environment,  rather  than  to  issues  ooncemed  with  descriptive  documen¬ 
tation. 
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4.  Legal  Issues 

Three  fundamental  legal  issues  shaped  the  development  of  our  proposed  generic  sys¬ 
tem  warranty  clause: 

1.  the  governments  burden  of  proof  respecting  breach  of  warranty  claims, 

2.  Vie  applicability  of  the  Weapon  Systems  Warranty  Act  and 

3.  the  need  for  careful,  case  by  case  tailoring  of  the  generic  clause. 

4.1.  Burden  of  Proof 

As  stated  by  FAR  Section  46.703(c),  *p]he  Government's  ability  to  enforce  the  warranty 
is  essential  to  Vie  effectiveness  of  any  warranty.'  Fundamental  to  this  essential  issue  of 
enforceability  is  the  two-part  burden  of  proof  that  is  imposed  on  the  government  with 
respect  to  warranty  claims  under  prevailing  federal  procurement  law.  First,  the  govern¬ 
ment  must  prove  by  a  preponderance  of  the  evidence  the  existence  of  a  defect  —  that 
is.  that  during  the  warranty  period,  conditions  have  developed  or  been  discovered  in  the 
warranted  product  that  are  inconsistent  with  the  condttions  specified  in  the  warranty. 
Eg.  U-Pax,  Inc..  HUD  BCA  No.  80-529-C11.  81-2  BCA  Paragraph  15410  (1980); 
Qanco  Co..  DOT  CAB  No.  75-22.  76-1  BCA  Paragraph  11823  (1976).  Second,  even 
after  proving  the  existence  of  a  defect.  Vie  government  must  ordinarily  prove  by  a 
preponderance  of  the  evidence  Viat  the  probable  cause  of  the  defect  is  attributable  to 
contractor  fault  under  the  warranty.  V.  It  appears  that  the  government  has  not  generally 
been  ab.*  to  meet  this  two-part  burden  with  respect  to  software.  The  generic  system 
warranty  clause  should  be  drafted  to  ease,  so  far  as  possible,  the  government's  burden 
of  proving  breach  of  warranty. 

4.1.1.  Burdvn  of  Proving  •  Defect. 

First,  the  government  must  prove  the  existence  of  a  defect  in  the  warranted  system.  In 
considering  this  aspect  of  Vie  burden  of  proof  problem  in  connection  with  a  generic  war¬ 
ranty  clause,  we  rejected  an  approach  to  software  warranty  clauses  that  limited  the  war¬ 
ranty  to  software  exclusively,  and  instead  used  a  system  approach  that  warranted  soft¬ 
ware  as  part  of  a  generally  warranted  system.  The  government's  burden  of  proving  a 
defect  may  be  unnecessarily  complicated  if  it  has  to  identify  the  defect  with  a  particular 
hardware  or  software  warranty.  Where  a  contractor  is  responsible  for  delivering  an  oper¬ 
ational  system,  the  government  should  not  have  to  bear  the  burden  of  isolating  and  prov¬ 
ing  a  defect  In  the  system’s  software,  computer  hareforare,  or  any  other  particular  compo¬ 
nent  of  the  system.  It  should  be  enough  that  the  delivered  system  is  demonstrably 
defective;  it  is  then  up  to  the  contractor  to  find  and  fix  the  defect(s).  This  system  ap¬ 
proach  is  consistent  with  our  observation  (see  Chapter  3)  that  the  contractor’s  product 
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under  a  system  acquisition  contract  is  an  operational  system,  and  that  the  system  is 
therefore  the  appropriate  subject  of  the  warranty. 

Further,  defects  for  purposes  of  system  warranty  coverage  should  be  defined  in  terms  of 
system  performance  requirements.  The  coverage  for  system  performance  requirements 
is  not  necessarily  instead  of,  but  it  is  in  addition  to,  more  traditional  warranties  against 
defects  in  workmanship  and  materials  or  against  failure  to  conform  to  design  specifi¬ 
cations.  If  the  wamanty  is  drafted  in  terms  of  the  system’s  contractually  established 
operating,  reliability,  and  maintainability  standards  —  which  Is  what  we  mean  by  a 
system’s  performance  requirements  —  a  demonstrable  failure  of  the  system  to  meet 
those  standards  should  be  sufficient  to  satisfy  the  government’s  burden  of  proof,  without 
a  need  to  isolate  the  cause  of  the  system  failure  in  particular  hardware  or  software 
defects. 

Critical  to  the  success  of  this  approach  to  warranting  software  through  system  perfor¬ 
mance  requirements  is  the  development  of  (1)  performance  standards  that  are  clear  and 
complete,  and  (2)  procedures  and  tests  that  can  measure  compliance  with  those  stan¬ 
dards  in  such  a  way  that  the  government  will  be  able  to  demonstrate  system  noncom¬ 
pliance  with  as  much  ease  as  possible.  Thus,  FAR  Section  46.703(c)  provides  that  en¬ 
forceability  depends  on  the  existence  of  a  defect  reporting  system  that  is  adequate  in 
terms  of.  among  other  things,  the  difficulty  in  establishing  the  existence  of,  and  the  re¬ 
sponsibility  for,  defects.  As  we  understand  it  in  light  of  discussions  with  DoD  personnel, 
existing  warranties  have  frequently  been  inadequate  because  they  have  not  been  tied  to 
carefully  defined  and  measurable  performance  requirements.  Nor  have  they  incorpo¬ 
rated  objective  and  mutually  agreed  upon  tests  for  measuring  and  verifying  compliance 
with  the  performance  requirements  that  have  been  stated.  As  a  result,  the  government 
has  not  been  able  to  carry  its  burden  of  proof  because  its  contracts  have  not  contained 
sufficiently  objective  and  demonstrable  standards  against  which  a  claim  for  breach  could 
be  measured. 

Under  the  system  performance  approach  to  software  warranties  such  as  we  propose, 
the  critical  matter  of  enforceability  is  ultimately  tied  less  to  generic  legal  drafting  issues 
than  to  specific  technical  ones;  the  warranty  is  only  as  good  as  the  technical  articulation 
of  system  performance  requirements.  Moreover,  the  applicable  performance  require¬ 
ments  for  any  given  procurement  must  be  developed  in  the  context  of  that  particular 
procurement  and  cannot  themselves  be  included  in  a  generic  model  clause  Itself.  Chap¬ 
ter  5,  Product  Specification,  addresses  issues  relevant  to  the  development  of  such  per¬ 
formance  requirements  and  verification  procedures. 
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4.1.2.  Government-Furnished  Equipment  and  the  Burden  of  Proof. 

Assuming  proof  of  the  existence  of  a  "defect"  as  defined  in  the  warranty,  the  second  part 
of  the  government’s  burden  is  to  prove  that  the  defect  is  the  responsibility  of  the  contrac¬ 
tor  under  the  warranty,  not  the  government.  The  effect  of  this  burden  is  that  the  govern¬ 
ment  must  generally  prove  that  the  defect  was  not  attributable  to  any  cause  for  which  the 
government  was  responsible.  See,  e.g.,  Lucerne  Construction  Corp.,  VACAB  No.  1494, 
82-2  BCA  Paragraph  16,101  (1982);  R.H.  Fulton,  Contractor,  IBCA  No.  769-3-69,  71-1 
BCA  Paragraph  8674  (1971);  Araco  Co.,  VACAB  No.  532,  67-2  BCA  Paragraph  6440 
(1967);  S&E  Contractors,  Inc.,  ASBCA  No.  11044,  67-1  BCA  Paragraph  6175  (1967); 
Jefferson  Construction  Co.,  ASBCA  No.  7008, 1962  BCA  Paragraph  3409  (1967).1 

This  burden  of  proof  can  adversely  affect  warranty  enforceability  where  some  defects  in 
system  performance  are  excluded  from  system  warranty  coverage.  Defects  attributable 
to  govemment-fumished  equipment  (GFE),  for  example,  are  generally  excluded  from 
warranty  coverage,  and  must  be  so  excluded  under  the  Weapon  Systems  Warranty  Act. 
See  Section  4.2  on  page  12. 

We  think  the  better  rule  of  law,  applicable  outside  the  narrow  context  of  federal  procure¬ 
ment  law,  is  that,  where  a  party  seeks  to  bring  itself  within  an  exception  to  a  contractual 
provision  —  such  as  an  exclusion  of  GFE  from  warranty  coverage  —  that  party  bears  the 
burden  of  proving  the  facts  necessary  to  bring  itself  within  that  exclusion.  E.g.,  New 
Britain  Machine  Co.  v.  Yeo,  358  F.2d  297  (6th  Cir.  1966);  Davies  Flying  Service  v. 
United  States,  216  F.2d  104  (6th  Cir.  1954);  Reece  Construction  Co.  v.  State  Highway 
Comm’n,  627  P.2d  361  (Kan.  Ct.  App.  1981);  Langv.  F.G.  Atwood  &  Co.,  Inc.,  65  A.2d 
194  (D.C.  Mun.  App.  1949).  This  is  especially  so  where  the  exclusion  is  set  forth  in  a 
separate  clause,  rather  than  just  as  a  proviso  to,  or  part  of,  a  single  general  clause.  See 
generally  29  Am.  Jur.  2d,  Evidence,  Section  144.  Under  this  rule,  to  avoid  its  warranty 
obligations,  the  contractor  would  bear  the  burden  of  proving  that  defective  system  perfor¬ 
mance  was  caused  by  GFE,  rather  than  the  government’s  having  to  isolate  the  cause 
and  prove  that  the  defect  was  not  attributable  to  GFE. 

Were  the  government  aggressively  to  pursue  the  matter  in  litigation  or  otherwise,  it  might 
successfully  clarify  federal  procurement  law  consistently  with  the  more  favorable  civil 
rule.  Careful  drafting  would  substantially  assist  in  this  effort.  Thus,  any  GFE  exclusion 
should  be  drafted  as  a  separate  provision,  and  should  not  be  included  within  the  contrac¬ 
tor  warranty  provision  Itself. 
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4.1 .2.1.  Contractually  Shifting  the  Burden. 

It  may  further  be  helpful  to  include  in  a  system  warranty  a  provision  that  explicitly  pro¬ 
vides  that  the  contractor  bear  the  burden  of  proving  government  fault  for  a  defect, 
whether  attributable  to  GFE  or  otherwise.  There  is  a  split  In  authority  respecting  the 
validity  of  such  contractual  provisions,  with  perhaps  the  weight  of  authority  holding  that 
parties  may  not  contractually  change  what  are  normally  considered  to  be  rules  of 
evidence.  See  generally,  29  Am.  Jr.  2d,  Evidence,  Section  13;  I  Wigmore  on  Evidence 
Section  7a  (Tillers  Rev.).  Until  the  issue  is  finally  decided,  however,  there  would  appear 
to  be  no  good  reason  not  to  include  such  a  provision  for  whatever  additional  protection  it 
may  provide. 

Moreover,  the  clause  should  be  drafted  to  define  any  GFE  exception  In  terms  of  contrac¬ 
tor  proof  of  GFE  fault.  By  making  the  burden  of  proof  an  element  of  the  exception  itself, 
rather  than  only  a  rule  of  evidence  for  proving  the  exception,  the  government  may  be 
able  to  increase  further  the  likelihood  that  a  court  or  board  of  contract  appeals  would  put 
the  burden  of  proving  the  exception  on  the  contractor. 

4.1. 2.2.  Tests  and  Procedures  for  Determining  GFE  Defects. 

In  the  final  analysis  the  best  method  for  easing  the  adverse  effects  of  the  government’s 
burden  of  proving  contractor  responsibility  for  defective  performance  is  to  develop  tech¬ 
nically  sound  criteria  and  prooedures  for  verifiabiy  isolating  system  failures  that  are  due 
to  GFE  from  failures  that  are  due  to  causes  within  the  contractor's  area  of  responsibility 
under  the  warranty.2  The  generic  clause  should  incorporate  such  tests  by  reference  and 
make  them  the  standard  for  applying  the  exception.  Like  the  performance  requirements 
and  verification  procedures  described  above  in  connection  with  proving  a  defect,  such 
criteria  and  procedures  can  only  be  developed  on  a  case  by  case  basis  depending,  for 
example,  on  the  system  involved,  what  GFE  is  used  and  how  it  is  incorporated  into  the 
system.  But  in  the  absence  of  technically  verifiable  tests  and  procedures  for  determining 
whether  or  not  performance  defects  are  caused  by  GFE,  the  government  will  have  little 
chance  of  proving  that  the  contractor  is  responsible  for  system  failure  under  the  war¬ 
ranty.  Chapter  7,  Problem  Detection  and  Isolation,  addresses  issues  relevant  to  the  de¬ 
velopment  of  such  verification  tests  and  procedures. 

4.2.  Applicability  of  the  Weapon  Systems  Warranty  Act 

The  generic  clause,  of  course,  should  be  drafted  to  conform  to  the  fundamental  require¬ 
ments  of  FAR  Sections  46.702-46.710,  which  govern  warranties  in  government  contracts 
generally,  and  DFAR  (defense  federal  acquisition  regulation  supplements)  Sections 
246.701-246.708,  which  are  warranty  regulations  specifically  promulgated  by  the  Depart¬ 
ment  of  Defense.  The  clause  should  also  conform,  we  believe,  to  the  Weapon  Systems 


Warranty  Act  of  1984  (WSWA),  10  U.S.C.  Section  2403,  and  to  the  DFAR  provisions 
implementing  WSWA,  DFAR  Sections  246.770-246.770-10. 

WSWA,  which  mandates  certain  warranty  requirements  for  government  acquisition  of 
"weapon  systems,"  Is  relevant  to  the  generic  system  warranty  clause  for  two  reasons. 
First,  although  we  understand  that  to  this  point  DoD  procurements  have  not  generally 
been  warranted  under  WSWA,  It  is  our  view  that  the  intended  scope  of  the  Act  is  very 
broad  in  the  context  of  defense  procurements,  and  that  its  applicability  should  be  care¬ 
fully  considered  in  connection  with  future  DoD  procurements.3  To  assure  the  broadest 
possible  applicability  for  the  model  clause,  therefore.  It  is  useful  to  develop  a  clause  that 
will  satisfy  the  specific  requirements  of  WSWA,  as  well  as  the  more  generally  applicable 
FAR  and  DFAR  warranty  clause  requirements. 

The  second  reason  WSWA  is  relevant  to  the  generic  clause  is  that,  whether  or  not 
WSWA  is  strictly  applicable  to  a  particular  DoD  procurement,  WSWA  applies  to 
"systems’  and  establishes  warranties  of  essential  performance  requirements  for  those 
systems.  Thus.  WSWA  provides  a  congressionally  approved  model  for  a  system  war¬ 
ranty  incorporating  essential  performance  requirements  —  the  approach  we  have  taken 
for  warranting  software.  As  such,  the  WSWA  warranty  requirements  provide  useful 
guidance  and  precedent  for  warranty  provisions  that  could  be  at  issue  in  later  litigation.4 

Where  Congress  has  specifically  addressed  performance  warranties  and  legislated  an 
approach  to  such  warranties,  enforceability  of  a  warranty  clause  will  be  improved  if  the 
clause  conforms  to  Congress’  approach.  DFAR  Section  246.703  indeed  encourages  ap¬ 
plication  of  WSWA  warranties,  even  where  not  strictly  required,  if  warranties  are  other¬ 
wise  to  be  obtained.  ("Acquisition  of  warranties  in  the  procurement  of  supplies  that  do 
not  meet  the  definition  of  a  weapon  system  ...  is  governed  by  FAR  46.7.  However, 
should  the  Government  elect  to  obtain  a  warranty  for  such  supplies,  contracting  officers 
should  negotiate  warranties  that  meet  or  exceed  the  requirements  of  246.770  [governing 
WSWA  warranties]  where  such  warranties  are  advantageous  and  in  accordance  with 
Department  policy.") 

4.3.  Tailoring 

A  further  warranty  fact  of  life  relevant  to  developing  a  generic  or  model  clause  is  that  a 
model  clause  is  just  that  —  a  model.  Such  a  generic  model  should  not  purport  to  resolve 
the  myriad  of  procurement-specific  Issues  that  will  arise  in  connection  with  particular 
procurements.  The  clause  we  have  developed  is,  therefore,  not  intended  as  a  form 
clause  to  be  simply  inserted  into  systems  acquisition  contracts.  As  earlier  noted,  the 
heart  of  the  clause  is  in  paragraphs  that  reference  performance  requirements,  and  in 


tests  and  procedures  that  establish  and  verify  compliance  with,  or  deviation  from,  those 
performance  requirements;  the  clause  similarly  references  tests  and  procedures  for  dis¬ 
tinguishing  defects  for  which  the  contractor  is  responsible  from  defects  in  QFE,  for  which 
the  contractor  is  not  responsible.  We  have  already  observed  that  such  requirements, 
tests,  and  procedures  can  be  developed  only  in  the  context  of  specific  procurements,  not 
generically.  Issues  specific  to  particular  procurements  —  and  negotiations  with  individ¬ 
ual  contractors  —  will  likely  also  require  carefully  tailored  provisions  relating  to  proce¬ 
dures  for  notification,  investigation,  and  resolution  of  claims  of  breach,  as  well  as  to  rem¬ 
edies,  exclusions,  limitations,  and  warranty  periods.  In  promulgating  model  clauses  for 
general  acquisition  purposes,  FAR  Section  76.710  recognizes  that  "because  of  the  many 
situations  that  may  influence  the  warranty  terms  and  conditions  appropriate  to  a  partic¬ 
ular  acquisition,  the  contracting  officer  may  vary  the  terms  and  conditions  of  the  clauses 
to  the  extent  necessary."  More  compellingly,  to  the  extent  that  WSWA  applies  to  a  given 
system  acquisition,  a  nongeneric,  case  by  case  approach  was  plainly  intended  by 
Congress5and  is  specifically  required  by  the  governing  DFAR  provisions.6 

In  short,  the  model  system  warranty  clause  can  be  designed  to  address  generic  require¬ 
ments  and  problems,  but  it  must  be  specifically  and  carefully  tailored  for  each  applica¬ 
tion. 


4.4.  Summary 

To  summarize  our  observations  on  some  of  the  legal  issues  underlying  a  generic  system 
warranty  clause,  a  generic  clause  should  take  account  of  the  requirements  of  WSWA 
and  should  provide  for  substantial  tailoring  on  a  case  by  case  basis.  Most  importantly.  S, 

the  system  warranty  clause  should  be  based  on  carefully  developed  performance  speci¬ 
fications  and  on  testing  and  measuring  procedures  that  can  verify  system  compliance 
with  the  contractual  requirements  and  help  determine  responsibility  for  system  defects. 

In  the  following  chapters,  we  discuss  approaches  and  methods  for  developing  such  sys-  _ 

tern  specifications  and  verification  procedures. 
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5.  Product  Specification 

A  key  aspect  to  consider  when  dealing  with  a  system  warranty  as  we  have  described  it 
above  is  the  product's  essential  performance  requirements.  These  can  be  defined,  and 
have  been  under  WSWA,  as  "the  operating  capabilities  and  maintenance  and  reliability 
characteristics  of  a  system  necessary  for  it  to  fulfill  the  military  requirement  for  which  the 
system  is  designed’  (OFAR  Section  246.770-1).  In  this  chapter,  we  address  issues  rele¬ 
vant  to  developing  such  essential  performance  requirements. 

Specifying  a  product’s  essential  performance  requirements  is  a  critical  component  of  the 
specification  activity.  Specifications  are  commonly  used  to  describe  a  product  and  to  act 
as  a  basis  for  product  testing  and  acceptance.  Requirements  specifications  should  also 
be  viewed  as  a  tool  for  acquiring  and  enforcing  a  product  warranty.  To  be  an  effective 
warranty  tool,  the  specifications  must  be  developed  in  a  way  that  simplifies  the  task  of 
warranty  enforcement.  They  must  be  clear,  concise,  consistent,  correct,  and  complete. 
Creating  specifications  with  these  characteristics,  however,  is  an  extremely  difficult  and 
error-prone  task.  To  aid  in  warranty  enforcement,  special  and  careful  attention  must  be 
paid  to  the  creation  of  the  specifications  (see  FAR  Sections  46.703(c)(5)&(6)). 

Electronic  systems  products  incorporating  computers,  which  are  the  subject  of  this  re¬ 
port,  are  often  large,  technically  complicated,  and  especially  difficult  to  specify.  The  col¬ 
lection  of  all  product  specifications  in  such  complex  systems,  even  after  considerable 
review,  may  not  completely  identify  all  aspects  of  the  product,  may  lack  clarity  in  some 
areas,  and  may  contain  inconsistencies.  A  wholesale  or  mechanical  application  of  war¬ 
ranty  clauses  to  a  complete  set  of  product  specifications,  therefore,  may  easily  lead  to 
problems  of  enforcement.  Thus,  as  a  practical  as  well  as  a  legal  matter  under  FAR 
Section  246.706-1 ,  it  is  necessary  to  determine  and  spell  out  exactly  what,  of  all  the 
things  that  make  up  the  product,  is  to  be  warranted.  Such  essential  requirements  should 
stand  separately  and  be  clearly  identified.  The  separation  should  allow  critical  review 
and  analysis  of  the  essential  requirements,  and  should  be  less  difficult  than  critical  re¬ 
view  of  the  entire  specification. 

There  are  three  basic  product-related  areas  that  must  be  considered  when  defining  a 
product's  essential  performance  requirements: 

1.  where  and  how  the  product  will  be  used  [environment], 

2.  what  the  product  does  [functionality],  and 

3.  how  well  the  product  does  it  over  time  [quality]. 
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These  areas  are  discussed  separately  below,  but  it  is  important  to  consider  them  togeth¬ 
er  to  determine  the  essential  performance  requirements  and  what  is  to  be  warranted  for 
a  particular  system.  Review  of  several  DoD  system  specifications  indicates  that  design 
constraints  should  be  separated  out  in  existing  specifications.  While  constraints  may  not 
apply  directly  to  the  specification  of  critical  requirements,  they  may  well  play  a  role  in 
warranty  enforcement. 


5.1.  Operational  Environment 

A  product  must  be  considered  in  relation  to  the  environment  in  which  it  operates.  The 
term  environment  is  often  used  to  describe  physical  conditions  such  as  temperature, 
humidity,  power,  and  vibration.  Environment,  as  used  here,  includes  these  physical  con¬ 
ditions.  It  also  includes  other  equipment  with  which  the  product  must  interact,  such  as 
communications  networks  and  other  government-furnished  equipment.  Special  attention 
must  also  be  paid  to  software  packages,  such  as  operating  systems,  that  are  provided 
by  the  government.  A  product  is  useful  only  If  it  operates  successfully  in  its  intended 
setting.  As  a  practical  matter,  it  is  usually  neither  possible  nor  economically  practical  to 
engineer  a  product  for  all  possible  environments.  It  is  mandatory  to  clearly  distinguish 
and  define  the  boundaries  between  a  product  and  its  environment  Those  points  where 
a  product  interacts  with,  or  is  affected  by.  its  environment  deserve  special  attention. 
These  interface  points,  and  the  conditions  and  interactions  that  occur  at  these  points, 
form  part  of  a  product's  essential  performance  requirements.  It  is  impossible  to  create  a 
description  of  a  product  without  a  precise  definition  of  its  boundary.  The  product  in¬ 
cludes  everything  inside  the  boundary.  The  product's  environment  includes  everything 
outside  the  boundary.  Without  a  clear  boundary,  it  is  impossible  to  define  what  the  prod¬ 
uct  is  supposed  to  do. 


As  a  very  simple  example,  consider  requirements  specifications  for  two  alphanumeric 
video  display  terminals:  the  first,  with  a  boundary  drawn  between  the  keyboard  and  the 
terminal  operator;  the  second,  with  a  boundary  drawn  between  the  terminal  and  the 
keyboard. 


•  In  the  first  case,  the  keyboard  is  part  of  the  product  and  the  operator  is  part 
of  the  environment.  In  this  case,  the  specifications  must  deal  with  issues 
such  as  keyboard  layout,  keycap  legends,  keyboard  physical  dimensions, 
pressure  required  to  activate  a  key,  and  tactile  feel  to  the  operator. 


In  the  second  case,  the  Interface  is  part  of  the  product  and  the  keyboard  is 
part  of  the  environment.  In  this  case,  the  specifications  will  deal  with  very 
different  issues.  These  include  physical  connection  between  terminal  and 
keyboard,  electrical  interface  between  terminal  and  keyboard,  content  and 
format  of  data  messages  passed,  rate  of  data  messages,  control  of  mes¬ 
sage  flow,  and  detection  and  handling  of  transmission  errors. 
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A  small  change  in  the  boundary  brings  about  the  need  for  very  different  specifications  of 
requirements.  It  aiso  presents  a  very  different  picture  and  statement  of  what  is  to  be 
warranted. 

This  separation  of  product  from  environment  is  crucial  at  an  early  stage  of  specification 
development  It  allows  the  specification  to  be  developed  in  a  coherent,  meaningful  way, 
and  aids  other  warranty -related  activities,  listed  below. 

1.  Separation  helps  Identify  the  points  at  which  the  product  Interfaces 
with  the  environment  For  each  interface  point,  it  Is  necessary  to  de¬ 
scribe  in  detail  how  the  product  deals  with  the  interface.  For  example, 
what  conditions,  data,  and  signals  does  the  environment  present?  If  the 
interface  is  provided  by  software,  what  is  the  interface  mechanism,  what 
data  flow  across  the  interface,  what  checking  for  proper  Interfaces  occurs, 
and  what  errors  are  reported?  What  functions  are  to  be  performed  by  the 
product  in  each  case?  How  are  problems  in  the  interface  to  be  recog¬ 
nized,  and  what  is  to  be  done  in  each  problem  situation? 

2.  Definition  and  specification  of  interface  points  aid  In  the  process  of 
test  specification  and  development  Tests  are  known  to  be  useful  dur¬ 
ing  the  development  and  acceptance  of  products.  Tests  are  aiso  important 
in  the  area  of  warranty  enforcement.  A  predefined  set  of  well  defined  inter¬ 
face  tests  greatly  aids  defect  detection  and  isolation  necessary  to  support 
warranty  enforcement. 

3.  A  dear  separation  between  product  and  environment  aids  In  deter¬ 
mining  the  Instrumentation  required  to  support  warranty 
enforcement.  Any  question  of  warranty  will  bring  questions  from  the  con¬ 
tractor  about  the  conditions  of  the  environment  at  the  time  of  a  failure. 
Predefined  instrumentation  that  monitors  the  condition  of  the  environment 
should  aid  defect  detection  and  isolation. 

Environment  specification  also  deals  with  defining  general  physical  conditions  of  the 
operating  environment  rather  than  interface  points.  These  physical  conditions,  e.g., 
heat,  relative  humidity,  shock,  and  vibration,  seem  well  understood.  They  are  not  dealt 
with  here  other  than  to  say  that  Instrumentation  and  recording  of  the  physical  conditions 
may  be  an  aid  to  warranty  enforcement. 


5.2.  Functionality 


Sw 


A  product  is  useful  and  valuable  only  if  It  does  what  it  is  purported  to  do.  What  a  product 
does  can  be  described  by  the  functions  it  performs.  In  many  real-time  systems,  each 
function  description  must  contain  a  specification  of  the  time  period  in  which  the  function 
must  occur.  From  a  warranty  standpoint  the  important  functions  are  those  that  occur  at 
the  boundaries  of  a  product  —  teat  is,  those  that  a  product  provides  to  its  environment. 
Internal  functions  are  necessary  to  support  the  operation  of  external  functions,  but  in  the 
area  of  product  warranty,  they  are  represented  by  their  observability  at  the  product 
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boundary.  Functions  provided  to  the  environment  form  part  of  a  product's  essential  per¬ 
formance  requirements. 

The  portion  of  the  specification  covering  functionality  should  answer  the  questions, 
"What  is  the  system  supposed  to  do?"  and,  "What  functions  will  it  perform  under  what 
conditions  within  what  time  periods?"  The  specification  of  functionality  must  relate  to  the 
specification  of  the  operational  environment  and  must  pay  careful  attention  to  the  points 
where  the  product  interfaces  with  the  environment.  In  many  cases,  it  may  be  necessary 
to  separate  functions  that  occur  in  the  normal  operating  environment  from  those  that 
occur  when  the  product  is  stressed  by  abnormal  conditions  in  the  environment,  e.g.,  un¬ 
usually  high  burst  data  rate,  toss  of  processing  power  due  to  hardware  malfunction,  and 
toss  of  communications  paths  due  to  defects  in  system  components  outside  the  product. 
The  key  point  here  is  that  specifying  what  to  do  under  the  normal  system  environment  is 
not  enough.  The  specification  should  also  define  what  must  be  done  during  times  of 
abnormal  conditions  in  the  environment,  e.g.,  abnormal  toad. 


Separating  functions  into  levels  allows  the  specification  of  different  reliability  and  availa¬ 
bility  measures.  There  are  cases  in  which  all  functions  provided  by  a  product  are  critical 
to  accomplish  the  mission  of  the  system,  but  In  practice  this  is  not  always  the  case. 
|  Separating  functions  into  critical,  noncritical,  and  possibly  other  levels  is  a  product- 

|  specific  activity  that  depends  on  the  needs  a  product  must  satisfy.  Specifying  levels  of 

1  functionality,  which  must  all  exhibit  ultra-high  reliability  and  availability,  may  well  lead  to 

I  products  that  are  "gold  plated”  —  extremely  expensive  to  produce  and  maintain. 

r 

!  5.3.  Quality 

The  third  product  area  that  must  form  part  of  the  essential  performance  requirements  is 
the  quality  of  a  product.  It  is  important  to  define  quality  measures  for  each  product, 
i  Quality  deals  with  how  well  the  product  performs  Its  functions  In  the  operating  environ- 

i  ment  over  time.  Quality  is  one  of  the  most  difficult  areas  of  product  specification.  Al¬ 

though  quality  is  often  easy  to  recognize,  it  Is  difficult  to  discuss  and  describe  in  measur¬ 
able.  quantitative  ways.  A  product  exhibits  quality  only  if  It  provides  the  required  set  of 
functions  to  the  outside  environment  when  they  are  required.  Quality  characteristics  of 
individual  components  of  a  product  are  secondary  to  the  quality  characteristics  of  the 
external  functions. 

i 
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From  a  warranty  standpoint,  two  key  specification  issues  must  be  dealt  with: 

1.  The  specification  must  be  unambiguous.  Required  quality  character¬ 
istics  must  be  measurable  in  a  quantitative  way.  The  measures  and  the 
methods  of  measurement  should  both  be  defined,  in  general,  the  following 
five  areas  must  be  defined  in  the  quality  specification: 

a.  What  Is  product  failure?  A  product  failure  definition  can  usually 
be  tied  to  the  product's  functional  specification.  A  product  failure 
occurs  when  the  product  does  not  do  what  the  functional  specifi¬ 
cation  says  it  is  supposed  to  do. 

b.  What  is  reliability?  Reliability  is  a  measurement  of  the  number  of 
failures  over  time.  Mean  Time  Between  Failures  is  often  used  to 
specify  required  reliability  characteristics.  MTBF  should  be  speci¬ 
fied  for  each  level  of  functionality  defined  for  the  product. 

c.  What  Is  recovery  and  repair?  Recovery  from  failure  should  spec¬ 
ify  what  actions  are  acceptable  to  restore  a  system  to  operation  fol¬ 
lowing  a  failure,  and  the  maximum  length  of  time  allowed  to  per¬ 
form  those  functions.  Recovery  is  not  the  same  as  repair.  In  some 
cases  —  for  example,  intermittent  failures  —  a  system  may  be  res¬ 
tored  to  operation  without  repairing  the  cause  of  the  failure. 
Recovery  from  failure,  even  if  rapid,  should  not  relieve  the  contrac¬ 
tor  from  the  responsibility  of  repairing  the  defect  that  caused  the 
failure. 

d.  What  Is  availability?  Product  availability  can  be  defined  as  the 
fraction  of  time  during  which  a  system  functions  without  failure.  It 
deals  with  both  reliability  and  recovery. 

e.  What  Is  maintainability?  Maintainability  deals  with  the  ease  with 
which  a  product  can  be  kept  in  an  operational  state  and  possibly  be 
extended  over  time.  While  maintainability  is  an  important  quality 
characteristic,  it  is  difficult  to  specify  in  a  quantitative  way.  Care 
must  be  taken  to  specify  maintainability  characteristics  in  a  way 
that  can  be  measured. 

2.  The  specification  must  define  quality  required  in  the  operational 
product.  It  should  not  confuse  delivered  quality  with  predicted  quality,  or 
with  the  methods  to  be  used  by  the  contractor  to  obtain  quality.  Quality 
assurance  methods  are  extremely  important  and  are  discussed  separately 
in  Section  8.4,  page  28.  Existing  product  specifications  deal  with  quality  in 
several  ways:  what  quality  is  required  in  the  delivered  product,  what  meth¬ 
ods  are  to  be  used  to  produce  a  quality  product,  and  what  role  do  reliability 
models  play  in  product  development.  The  methods  and  quality  predic¬ 
tions,  however,  are  not  the  subject  of  a  performance  warranty.  From  the 
warranty  standpoint,  the  specification  should  clearly  separate  the  definition 
of  required  quality  from  other  quality  considerations.  The  warranty  must 
cover  the  end  result  of  the  engineering  process:  the  quality  of  the 
delivered  product  Methods  to  achieve  quality  cannot  be  warranted  and 
should  be  discussed  separately  to  avoid  confusion  and  promote  warranty 
enforcement. 


5.4.  Constraints 


Existing  specifications  deal  with  an  area  separate  from  functionality,  environment,  and 
quality.  This  area  —  constraints  —  covers  restrictions  placed  on  the  contractor’s  devel¬ 
opment  process  and  defines  characteristics  of  individual  product  components.  Sections 
covered  include  standards  to  be  followed,  methods  to  be  used,  attributes  of  product 
components,  and  restrictions  on  component  interfaces.  Other  areas  specific  to  the  indi¬ 
vidual  product  are  also  included. 

These  constraints  are  important  and  should  remain  in  the  specification.  Many  describe 
process  and  component  characteristics  that  have  proven  useful  in  delivering  quality 
products.  The  constraints,  however,  may  make  obtaining  and/or  enforcing  a  perfor¬ 
mance  warranty  more  difficult.  Although  they  should  continue  to  be  included  in  the  spec¬ 
ifications,  they  should  be  clearly  separated  from  the  essential  performance  require¬ 
ments.  They  should  also  be  analyzed  carefully  to  insure  they  do  not  contradict  the 
product's  essential  performance  requirements. 
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6.  Product  Problems 


This  chapter  describes  the  problems  that  occur  in  a  developing  operational  system.  It 
describes  the  types  of  failures  that  arise,  the  reasons  for  these  failures,  and  then 
proceeds  to  give  an  overview  the  failures  most  relevant  to  the  warranty  conditions.  The 
chapter  then  discusses  the  remedies  that  apply,  and  clearly  distinguishes  between  fixing 
problems  and  restoring  the  system  to  operational  status. 

A  defect  for  warranty  purposes  is  a  deviation  from  warranted  specifications,  including 
essential  performance  requirements  as  fixed  by  the  contract. 

A  failure  occurs  when  the  system  has  been  working,  ceases  to  work,  and  some  opera¬ 
tional  loss  of  availability  occurs.  Failures  may  be  caused  by  defects  in  the  system,  or  a 
pattern  of  failures  may  constitute  a  performance  defect.  Failures  can  be  classified  by 
their  consequences  as  those  that: 

1.  cause  degraded  operation  of  the  system, 

2.  cause  the  system  to  be  unavailable  for  some  time, 

3.  cause  hazardous  situations  to  occur. 

Obviously,  all  failures  should  be  avoided,  but  those  that  may  lead  to  hazardous  situa¬ 
tions  must  definitely  be  eliminated  in  the  design  process. 


6.1.  Reasons  for  Failure 

There  are  four  basic  reasons  for  failure: 

•  birth  defects,  which  occur  when  a  component  is  new,  and  fails  shortly  after 
installation 

•  wear  out,  which  occurs  when  a  component  has  been  in  use  for  some  time, 
and  a  part  is  out  of  tolerance  due  to  wear  and  tear 

•  infrequent  occurrence  of  operating  conditions  exposing  a  defect 

•  incorrect  maintenance  actions 

The  effects  of  failures  on  the  operation  of  the  system  can  also  be  lumped  into  two  types: 

•  persistent  failures,  which  occur  each  time  a  condition  arises,  and 

•  intermittent  failures,  which  seem  to  occur  randomly,  though  in  practice  may 
reoccur  each  time  an  infrequent  combination  of  internal  states  and  input  se¬ 
quences  is  encountered. 

Most  failures  are  detected  during  the  building,  testing  and  installation  of  a  system.  Once 
the  system  is  in  operation,  the  failures  that  occur  can  be  categorized  as  described  be¬ 
low: 


1.  Hardware  wear  out  (causing  persistent  or  intermittent  failures),  which  can 
be  remedied  by  replacing  a  bad  part  with  a  good  part.  This  type  of  failure  is 
the  one  that  is  best  understood,  and  conventional  reliability  theory  models 
such  failures  well.  The  reliability  and  availability  of  a  system  can  be 
predicted  from  the  expected  failure  rates  of  components,  and  the  redun¬ 
dancy  and  fault  tolerance  can  be  designed  into  the  system. 

2.  Hardware  or  software  failures  due  to  design  defects.  These  can  be  difficult 
failures  to  resolve,  since  performance  failures  due  to  system  defects  are 
often  not  easily  reproducible,  and  they  can  occur  infrequently.  These  are 
basically  design  flaws,  and  are  not  well  modeled  by  conventional  reliability 
theory. 

3.  Failures  due  to  changes  in  the  environment.  These  can  range  from 
changes  in  the  physical  environment  surrounding  the  hardware,  to  failures 
encountered  after  software  upgrades  are  made  to  the  system,  for  example, 
replacing  the  operating  system. 


6.2.  Remedies 

The  basic  remedies  that  apply  to  the  failure  conditions  are  listed  below. 

1 .  For  a  persistent  hardware  failure,  replace  the  bad  component. 

2.  When  the  software  fails  to  perform  a  function  persistently,  redesign  and 
reinstall  the  software  causing  the  failure. 

3.  Intermittent  failures  can  be  due  to  hardware  failure,  hardware  defects,  or 
software  defects.  For  a  defect,  isolate  and  fix  the  defect,  then  reinstall  the 
updated  hardware  and/or  software  in  the  system.  Often  installation  of  new 
modules  has  to  be  done  carefully,  with  special  software  being  introduced 
and  executed  to  transform  any  populated  data  structures  from  the  ‘old* 
structure  to  the  modified  structure.  The  system  can  often  be  restored  to 
operational  status  without  isolating  and  fixing  the  defects  by  one  of  the 
methods  outlined  below. 

•  A  warm  restart,  in  which  the  system  is  restored  to  operation  in  the 
same  state  as  when  it  failed. 

•  A  cold  restart,  in  which  the  system  is  reinitialized  to  some  previous 
state,  but  usually  with  a  loss  of  some  information  at  the  time  of 
failure.  This  also  takes  considerably  longer  than  a  warm  restart. 


6.3.  Warranty  Issues 

The  intent  of  a  warranty  is  to  have  the  contractor  fix  aH  defects  within  the  scope  of  the 
warranty.  However,  fixing  a  software  defect  can  often  lead  to  the  Introduction  of  a  fur¬ 
ther  defect,  so  defect  fixing  should  not  be  routinely  postponed,  but  should  be  performed 
in  a  timely  manner.  For  warranty  purposes.  It  is  important  to  distinguish  between  fixing 
the  defects  and  recovering  operational  capability,  which  is  merely  fixing  the  symptoms 


I 

This  is  not  intended  to  downplay  the  recovery  issues  —  failures  will  occur,  and  a  good 
[  recovery  procedure  will  reduce  the  effect  of  those  failures  on  the  availability  of  the  sys- 


Probtems  Involving  the  effects  of  software  testing,  instrumentation,  and  other  issues  on 
the  warranty  are  presented  in  Chapter  7. 


7.  Problem  Detection  and  Isolation 


Chapter  6,  Product  Problems,  outlined  the  types  of  failures  that  occur  in  a  deployed  sys¬ 
tem,  and  how  they  can  be  categorized  and  remedied.  Unfortunately,  detecting  and 
isolating  defects  is  a  difficult  time-consuming,  labor-intensive  effort  In  current  practice,  it 
is  further  exacerbated  by  the  lack  of  instrumentation  to  record  secondary  symptoms,  and 
the  lack  of  tools  to  analyze  the  data  that  get  recorded. 

7.1.  Boundaries  with  the  Environment 

In  deployed  mission  critical  computer  resource  (MCCR)  systems,  it  is  often  more  difficult 
to  isolate  a  defect  than  to  fix  it.  In  view  of  the  government’s  burden  of  proof,  enfor¬ 
ceability  of  any  warranty,  therefore,  is  critically  related  to  the  definition  of  demonstrable 
defects.  One  of  the  difficulties  in  satisfying  the  burden  of  proof  is  in  determining  the 
boundaries  of  the  product  under  warranty.  The  basic  question  is,  "Does  the  defect  reside 
within  the  product,  or  within  the  environment  of  which  the  product  is  a  part?”  A  reason¬ 
able  way  to  resolve  this  problem  is  outlined  below. 

1.  In  the  specification,  the  government  should  state  that  boundary  problems 
will  be  resolved  by  the  execution  of  tests  on  the  system  or  on  the  recorded 
symptoms.  The  government  must  describe  the  extent  of  the  tests  at  this 
time. 

2.  During  the  design  process,  these  tests  will  be  described  in  detail  and  ap¬ 
proved  by  the  government  as  part  of  the  quality  assurance  program.  The 
tests  should  be  automated  as  much  as  possible. 

3.  When  a  deviation  from  the  system’s  essential  performance  requirements 
occurs,  the  appropriate  agreed-upon  tests  will  be  conducted  to  determine 
responsibility  for  the  defect. 

7.2.  Instrumentation  and  Analysis 

Until  the  problem  of  isolating  and  fixing  the  defects  is  alleviated,  the  contractor  will  al¬ 
ways  be  tempted  to  justify  the  failures,  rather  than  fix  the  defects.  Hence,  one  way  of 
enhancing  warranty  enforcement  is  to  improve  the  process  of  isolating  and  fixing  the 
defects.  This  section  describes  these  issues  in  more  detail. 
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In  general,  the  most  difficult  types  of  failures  to  isolate  are  infrequent,  intermittent  ones 
that  'crash*  the  system  and  require  a  recovery  mechanism  to  restart  it.  If  these  failures 
do  not  cause  a  hazardous  condition,  or  a  specified  function  to  work  incorrectly,  they  can 
only  be  resolved  by  invoking  the  reliability  clauses.  If  the  failure  rates  are  within  the 
specified  range,  then  the  users  of  the  system  will  probably  be  able  to  live  with  them.  If 
the  failure  rates  are  outside  the  specified  range,  then  the  system  is  defective  and  must 
be  fixed.  In  many  installations,  there  are  so  few  symptoms  describing  the  failure  that 
isolating  the  cause  of  the  defect  is  very  difficult.  Some  options  for  making  the  isolation 
less  difficult  are  given  below. 

1.  Require  that  the  hardware  components  have  Built  In  Tests,  which  will  help 
isolate  hardware  defects  from  software  defects. 

2.  Build  in  instrumentation  to  measure  and  record  in  a  timely  manner  state 
variables,  significant  state  transitions,  exceptional  conditions,  and  environ¬ 
mental  conditions.  This  is  necessary  to  provide  secondary  symptoms  of 
the  failure  condition.  The  instrumentation  should  be  able  to  be  turned  on 
and  off,  and  the  levrl  of  detail  recorded  should  be  selectable.  The 
recorded  data  should  be  transportable  to  another  environment  for  analysis. 
Tactical  requirements  must  have  precedence  over  data  extraction. 

3.  Provide  interfaces  to  external  data  collection  and  recording  devices. 

4.  Build  tools  to  filter  and  analyze  the  recorded  data  to  help  determine  the 
cause  of  the  failure  and  isolate  the  defect. 

5.  Monitor  the  appropriate  environmental  conditions,  such  as  temperature, 
humidity,  and  power. 


7.3.  Repair  of  Defects 

Once  a  software  defect  has  been  isolated,  it  has  to  be  fixed.  This  requires  changing  one 
or  more  software  components  in  the  deployed  system,  and  should  be  done  under  a  strict 
configuration  management  policy.  However,  before  the  updated  software  is  installed,  it 
should  undergo  extensive  testing  to  make  sure  it  performs  all  of  the  functions  of  the 
older  version,  and  does  not  contain  any  discernible  defects.  When  the  update  has  been 
made,  sufficient  on-site  testing  should  occur  to  ensure  that  the  new  product  meets  the 
essential  performance  requirements  of  the  contract. 
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8.  Administrative  Issues 


The  warranty  of  a  system  involves  not  just  legal  and  technical  issues,  but  many  adminis¬ 
trative  issues  as  well.  Since  these  issues  are  vital  to  resolving  the  warranty  problem, 
they  have  been  gathered  together  in  this  chapter. 

8.1.  Maintenance 

The  government  often  performs  the  maintenance  on  a  deployed  system  with  govern¬ 
ment  personnel,  or  hires  an  outside  contractor  (not  necessarily  the  systems  develop¬ 
ment  contractor)  to  perform  the  maintenance.  This  creates  problems  since  failures  can 
be  blamed  on  badly  performed  maintenance,  and  the  burden  of  proof  then  rests  on  the 
government  to  prove  that  the  most  likely  cause  of  the  failure  was  a  defect  existing  in  the 
delivered  product.  The  government  should  consider  these  warranty  issues  when  making 
the  choice  between  having  the  maintenance  done  organically,  by  the  original  contractor, 
or  by  another  contractor. 

A  second  warranty  problem  will  arise  if  the  development  contractor  is  not  performing 
maintenance.  It  may  be  difficult  to  obtain  contractor  responsibility  for  the  availability  and 
Mean  Time  To  Repair  (MTTR)  criteria  defined  for  the  product  In  the  essential  perfor¬ 
mance  requirements.  These  characteristics  are  obtained  by  a  combination  of  the  quality 
of  the  product  and  the  quality  of  the  maintenance  activities.  Holding  the  contractor 
responsible  for  the  actions  of  others  will  complicate  warranty  enforcement  problems. 


8.2.  Specification 

Specifications  were  discussed  In  detail  previously.  The  specifications  must  be  well  writ¬ 
ten  if  a  warranty  is  to  be  enforceable.  It  is  the  responsibility  of  the  Systems  Program 
Office  (SPO)  to  have  dear,  unambiguous,  complete,  and  testable  spedfications. 
"Developing  Reliable  Space  Flight  Software,"  by  Li  Col.  Ed  Koss.  details  methods  lead¬ 
ing  to  the  acquisition  of  quality  products.7  Spedfication  techniques  are  induded  in  those 
methods  and  receive  heavy  emphasis.  The  paper  provides  lists  of  things  to  do  and 
things  to  avoid  in  writing  specifications.  The  specifications  should  dearly  describe  not 
only  functionality  and  performance,  but  also  degraded  operation,  failure  conditions,  over¬ 
load  conditions,  recovery  considerations,  and  safety  issues. 


8.3.  Process 


The  process  of  developing  the  system  must  be  such  that  a  high  quality  product  that 
meets  all  the  functional,  performance,  and  reliability  requirements  in  the  specifications 
can  be  produced.  Military  standard  2167  describes  in  detail  the  government’s  approach 
to  this  problem,  and,  although  this  document  is  far  from  perfect,  it  does  emphasize  that  a 
well  defined  process  should  be  followed  to  produce  a  high  quality  product.  This  requires 
a  commitment  on  the  part  of  the  SPO  to  follow  the  design  details  technically  and  to  en¬ 
sure  that  the  details  are  given  on  schedule  and  within  budget. 

8.4.  Quality  Assurance  (QA) 

The  enforcement  of  quality  assurance  practices  should  ensure  delivery  of  a  satisfactory 
product.  However,  it  must  always  be  stressed  that  quality  is  designed  into  a  system,  and 
defects  are  tested  out  of  a  system.  Quality  assurance  is  only  effective  if  it  is  combined 
with  good  design  practices  and  a  well  crafted  warranty  to  cover  the  remaining  defects. 
Some  further  comments  are  given  below. 

1 .  Military  standard  21 68  describes  QA  procedures. 

2.  Prototyping  should  be  done  where  appropriate  to  reduce  risks  of  concep¬ 
tual  errors. 

3.  Factory  acceptance  tests  should  test  functionality,  performance,  and 
reliability  in  a  simulated  environment  before  shipment.  Detecting  and  fixing 
defects  is  easy  and  Inexpensive  in  this  environment.  Acceptance  of 
delivery  will  make  it  more  difficult  to  isolate  and  fix  defects. 

4.  Field  acceptance  tests  should  be  run  after  the  system  is  installed  and 
working  in  the  final  environment,  and  before  acceptance  of  the  system  by 
the  government.  During  Installation,  there  are  usually  knowledgeable  con¬ 
tractor  people  on-site;  this  is  the  time  to  correct  as  many  remaining  defects 
as  possible.  In  some  sense  this  is  also  a  critical  time  in  the  decision¬ 
making  process,  especially  if  the  installed  system  works  well  with  "only  a 
few  flaws,”  and  the  operational  command  'needs*  the  system  to  perform 
its  function. 

8.5.  Cost  Considerations 

The  cost  of  a  warranty  must  always  be  weighed  against  the  benefits  the  warranty  pro¬ 
vides  beyond  those  available  through  other  maintenance,  specification,  and  quality  as¬ 
surance  methods.  A  contract  with  an  enforceable  warranty  will  cost  more  up  front  than  a 
contract  with  no  warranty  or  with  a  relatively  unenforceable  warranty.  If  the  clause  is 
perceived  to  provide  the  government  with  substantial  and  enforceable  warranty  protec¬ 
tion,  contractors  will  want  to  be  paid  for  giving  that  protection.  Moreover,  the  expected 
cost  of  providing  warranty  protection  on  systems  developed  for  a  particular  acquisition 
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will  not  be  spread  over  multiple  purchasers  as  in  the  ordinary  commercial  setting,  but  will 
be  borne  wholly  by  a  single  purchaser  —  the  government.  Warranty  cost  problems  may 
be  further  exacerbated  by  pricing  difficulties  where,  for  example,  acquisitions  are  of  state 
of  the  art,  unproven  systems  with  no  performance  or  maintenance  history,  or  where  con¬ 
tractors  are  providing  performance  warranties  on  systems  they  did  not  design. 

All  this  said,  if  a  contract  Is  properly  administered,  contracting  for  an  enforceable  war¬ 
ranty  for  particular  systems  may  be  cost  effective  in  the  long  run,  since  the  government’s 
burden  of  proving  breach  of  warranty  will  be  eased,  and  the  government  will  not  have  to 
pay  the  costs  to  "fix"  the  system  to  perform  as  it  should  have.  The  cost  effectiveness  of 
a  rigorous  system  warranty  should  be  carefully  evaluated  on  a  case  by  case  basis  in 
light  of  other  available  quality  assurance  mechanisms. 

8.6.  Government-Furnished  Equipment 

If  the  system  specified  by  the  government  contains  a  substantial  array  of  both  QFE  and 
contractor-supplied  equipment,  then  the  warranty  will  be  difficult  to  enforce,  since  the 
boundaries  of  responsibility  will  be  unclear.  Before  deciding  to  use  GFE  procurement, 
the  government  agency  should  consider  the  viability  of  receiving  an  enforceable  war¬ 
ranty  for  the  portion  of  the  system  not  covered  under  the  GFE,  and  the  cost  of  realizing 
the  warranty.  The  effort  of  defining  a  set  of  tests  to  isolate  GFE  defects  from  defects  in 
contractor-supplied  equipment  should  be  estimated,  as  well  as  the  effort  of  maintaining 
and  executing  these  tests.  A  cost/benefit  analysis  should  then  be  conducted,  comparing 
GFE  savings,  warranty  cost  and  maintenance  costs. 

8.7.  System  Enhancements  During  Development 

The  contracted  systems  tend  to  be  large,  complex,  and  on  the  leading  edge  of  tech¬ 
nology.  In  addition,  there  is  usually  an  extended  time  period  between  the  award  of  the 
contract  and  the  deployment  of  the  system,  during  which  enhancements  to  the  system 
are  defined.  The  mechanisms  for  including  the  enhancements  vary  from  agency  to  agen¬ 
cy.  but  in  many  cases,  the  enhancements  do  not  cause  changes  to  the  specifications, 
but  are  agreed  to  on  a  piecemeal  basis.  This  causes  problems  with  the  product  war¬ 
ranty.  Since  there  is  no  single  document  describing  the  system  specification,  ambiguous 
interpretations  of  the  effects  of  the  enhancements  can  be  made.  The  warranty  issues 
must  be  resolved  with  each  enhancement,  and  the  government  must  protect  itself  at  in¬ 
itial  contract  time  against  purchasing  a  warranty  that  cannot  be  updated  in  a  cost- 
effective  manner  to  include  enhancements. 


8.8.  System  Enhancements  After  Deployment 

The  system  is  initially  installed  with  a  "baseline"  product,  and,  as  defects  are  found  and 
fixed,  the  system  may  be  changed  to  include  the  remedies  to  these  defects,  in  addition, 
the  system  may  be  changed  to  increase  its  functionality,  or  improve  its  performance,  in 
"block  releases."  After  so  many  block  releases,  a  new  baseline  may  be  created  for  the 
system.  If  the  system  baseline  is  still  under  warranty,  and  enhancements  are  introduced 
as  a  block  release,  how  does  this  affect  the  original  warranty  if  the  system  now  exhibits 
rates  inconsistent  with  essential  performance  requirements  failures?  This  can  be 
resolved  in  a  manner  similar  to  that  described  in  Section  7.1  (page  25)  for  distinguishing 
between  product  errors  and  environmental  errors  by  devising  test  procedures  to  estab¬ 
lish  the  source  of  failures.  The  crucial  problem  occurs  if  there  is  a  defect  that  is  benign  in 
the  baseline,  but  causes  a  failure  of  essential  performance  in  the  block  release.  This 
type  of  defect  cannot  be  found  by  merely  "restoring  to  baseline"  and  waiting  for  the 
failure  to  occur. 

8.9.  Failure  Reporting 

A  meaningful  failure  reporting  scheme  must  be  devised  and  implemented  if  warranty  en¬ 
forcement  is  to  be  realized.  The  failure  report  and  its  supporting  documentation  should 
contain  at  least  the  information  detailed  below. 

1 .  Downtime  and  recovery  time,  in  order  to  generate  the  reliability,  availabil¬ 
ity,  and  maintainability  metrics. 

2.  Results  of  diagnostic  tests. 

3.  Details  of  both  primary  and  secondary  error  and  failure  symptoms  for  anal¬ 
ysis  and  evaluation. 

In  addition,  each  failure  should  be  tracked  from  its  occurrence  to  its  resolution,  and  oper¬ 
ational  personnel  should  receive  sufficient  training  to  perform  these  tasks. 

8.10.  Acceptance  Testing 

System  acceptance,  which  ordinarily  starts  the  warranty  period,  is  usually  done  based 
on  a  Factory  Acceptance  Test  (FAT)  and  a  Field  Acceptance  Test  (FIAT).  Some  com¬ 
ments  on  both  sets  of  tests  are  given  below. 
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8.10.1.  Factory  Acceptance  Tests. 

By  the  very  nature  of  the  factory  environment,  factory  acceptance  tests  can  only  demon¬ 
strate  system  conformance  capabilities,  since  the  field  environment  can  rarely  be  com¬ 
pletely  simulated  for  the  test.  However,  there  are  many  things  that  can  be  done  to  in¬ 
crease  confidence  in  the  product,  some  of  which  are  enumerated  below. 

1 .  Most  of  the  functionality  of  the  specification  can  be  tested  by  well  designed 
test  procedures,  and  designing  the  software  to  be  testable  substantially  im¬ 
proves  this  capability. 

2.  Overload  conditions  cannot  be  simulated  in  detail  in  the  factory  environ¬ 
ment.  For  example,  it  is  rarely  possible  to  fly  hordes  of  airplanes,  flocks  of 
birds,  cruise  missiles,  and  other  objects  around  the  radar  installations  in  a 
factory  environment.  It  is  possible,  however,  to  isolate  the  parts  of  the  sys¬ 
tem  that  must  operate  under  these  conditions,  and  emulate  the  conditions 
in  a  test  setting  to  validate  that  the  software  performs  as  specified  when 
overload  conditions  arise. 

3.  Often  the  product  must  conform  to  certain  spare  capacity  requirements, 
but  the  FAT  cannot  create  an  environment  emulating  the  fully  loaded 
operating  conditions.  In  this  case,  the  government  and  the  contractor 
should  agree  on  some  formula  for  extrapolation  to  the  final  environment, 
and  the  FAT  should  demonstrate  that  the  extrapolation  is  reasonable,  and 
the  spare  capacity  and  system  performance  can  be  satisfied. 

4.  Failure  conditions,  graceful  degradation,  and  recovery  should  all  be 
thoroughly  tested. 

The  main  emphasis  in  this  area  is  on  error  classification.  The  system  should  not  pass 
FAT  with  unresolved  high  risk  items  outstanding,  such  as  unexplained  crashes.  If  time 
criticality  is  predicted  to  force  acceptance  and  continued  removal  of  known  defects  dur¬ 
ing  installation,  the  warranty  should  be  extended  to  provide  a  full  warranty  period  follow¬ 
ing  removal  of  those  defects. 

8.10.2.  Field  Acceptance  Tests. 

Acceptance  should  also  be  contingent  on  the  acceptable  operation  of  the  system  in  the 
field.  In  field  acceptance  tests,  normal  operating  conditions  are  in  effect,  and  the  system 
can  be  verified  to  meet  these  conditions,  including  reliability,  availability,  and  maintain¬ 
ability.  However,  the  system  has  often  been  specified  to  meet  certain  overload  con¬ 
ditions,  stressful  operating  conditions,  and  environmental  conditions,  some  of  which  may 
not  occur  naturally  before  acceptance  or  even  during  the  warranty  period.  The  govern¬ 
ment  should  be  confident  that  the  correct  actions  will  be  taken  should  these  conditions 
arise.  Hence,  there  is  a  need  for  special  field  acceptance  tests  emulating  each  such  con¬ 
dition. 


9.  FPS-1 17  Study 

We  decided  early  in  this  project  that  a  warranty  is  a  real-world  legal  instrument  used  to 
solve  real-world  problems,  and  that  our  study  should  focus  on  actual  problems  rather 
than  hypothetical,  abstract  issues.  We  thought  that  an  understanding  of  an  existing 
product  and  its  history  would  focus  our  thinking  and  drive  us  to  treat  issues  that  are 
relevant  to  those  actually  involved  in  the  process  of  system  acquisition,  development, 
deployment,  and  maintenance. 

Discussions  with  DoD  personnel  indicated  that  the  FPS-1 17  Seek  Igloo  radar  system 
would  be  a  good  candidate  for  study.  It  is  a  deployed  system  and  is  being  maintained. 
Deployment,  operation,  and  maintenance  activities  have  uncovered  problems  in  the  sys¬ 
tem,  and  problem  resolution  has  been  difficult  and  lengthy.  A  warranty  should  address 
the  problems  in  the  FPS-1 17  product  and  program. 

Our  study  of  the  FPS-1 17  was  valuable.  We  had  access  to  requirements  documen¬ 
tation,  summary  error  data,  and  project  personnel.  Choosing  an  existing  system  gave  us 
the  advantage  of  hindsight  —  both  ours  and  the  hindsight  of  those  who  have  been  in¬ 
volved  in  the  FPS-1 17  project. 

The  balance  of  this  chapter  discusses  the  FPS-1 17.  The  discussion  is  divided  into  four 
sections:  requirements  specification,  quality  assurance,  system  acceptance  and  deploy¬ 
ment,  and  operation  and  maintenance.  This  chapter  is  intended  to  help  the  reader  gain  a 
better  understanding  of  what  we  are  saying  in  the  report  by  relating  our  points  to  an 
existing  system.  We  are  not  knowledgeable  in  the  complex  area  of  radars,  and  this 
missing  skill,  along  with  time  constraints,  may  have  caused  us  to  overlook  areas  or  mis¬ 
interpret  what  we  read  or  heard.  The  discussion  is  not  a  criticism  of  what  has  been  done 
in  the  past.  We  recognize,  for  example,  that  the  FPS-1 17  specification  was  written 
seven  years  ago  and  that  more  recently  developed  specifications  already  incorporate 
much  of  what  we  are  saying. 


9.1.  Requirements  Specification 

Our  analysis  is  based  on  the  specification  titled  "System  Specification  For  Seek  Igloo 
Minimally  Attended  Radar  (MAR)  Radar  System  AN/FPS-117  (V)."  In  reviewing  the 
specification,  we  attempted  to  isolate  the  system's  essential  performance  requirements 
to  answer  the  following  questions: 

1.  What  Is  the  system  supposed  to  do? 

2.  For  each  failure  reported  on  the  FPS-117,  which  requirement  was  not 
met? 
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Answering  these  questions  proved  to  be  a  difficult  task.  The  requirements  section  of  the 
specification  (3.0)  deals  with  a  variety  of  issues  including  functionality,  quality,  environ¬ 
ment,  and  design  constraints.  These  Issues  are  not  easily  separated,  making  it  difficult 
to  determine  answers  to  our  simple  questions. 

Section  3.0  begins  with  a  general  description  of  the  system  and  the  mission  the  system 
is  to  accomplish.  This  is  followed  by  a  set  of  functional  area  schematic  diagrams  of  the 
system.  To  aid  the  following  discussion,  a  slightly  embellished  version  of  one  of  these 
diagrams  is  included  in  Figure  9-1. 
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Figure  9-1 :  Final  Configuration 

The  diagram  clearly  distinguishes  between  the  product  and  its  environment.  Everything 
inside  the  double-lined  rectangle  is  part  of  the  product;  everything  outside  the  double- 
lined  rectangle  is  part  of  the  environment.  The  points  at  which  the  product  interfaces  to 
its  environment  are  indicated  by  lines  that  pass  through  the  walls  of  the  double-lined 
rectangle.  This  simple  diagram  oould  have  been  used  to  aid  the  following  activities. 
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1.  Definition  of  functions  and  characteristics  Included  In  the  product’s 
essential  performance  requirements.  The  product's  essential  perfor¬ 
mance  requirements  must  include  a  definition  of  the  functions  and  charac¬ 
teristics  of  the  product  at  the  external  interface  points.  These  are  dearly 
marked  in  the  diagram  as  lines  a,b,d,e,f,g,  and  h.  For  each  interface,  it  is 
necessary  to  describe  die  functions  performed  there  and  other  Interface 
characteristics. 

2.  Definition  of  tests  and  procedures  to  aid  warranty  enforcement  En¬ 
forcement  of  the  warranty  of  a  product's  essential  performance  character¬ 
istics  requires  careful  attention  to  the  external  interfaces.  For  example,  the 
functions  provided  by  interface  b  indude  sending  messages  to  the 
JSS/ROCC  Modem  (which  in  turn  relays  the  messages  over  satellite  link  to 
the  ROCC).  One  of  the  predominant  failures  found  in  the  problem  reports 
we  reviewed  is  reported  as  “no  data  to  ROCC."  To  determine  if  the  prob¬ 
lem  is  caused  by  the  product,  it  will  be  necessary  to  develop  procedures 
and  tests  similar  to  the  following: 

•  Insure  power  (interface  a)  arrives  at  system  properly.  Power 
monitoring  equipment  could  provide  a  history  of  power  status  over  a 
period  of  time. 

•  Test  to  insure  proper  operation  of  ROCC  Console. 

•  Test  to  insure  proper  operation  of  communications  path  between 
ROCC  Console  and  JSS/ROCC  Modem. 

•  Test  to  Insure  proper  operation  of  communications  path  between 
JSS/ROCC  Modem  and  Process  and  Control  Group  (interface  b). 

Part  of  this  test  must  be  provided  by  the  contractor,  since  it  must 
execute  on  the  contractor’s  equipment. 

•  External  interfaces  (e,f,g,  and  h)  should  not  need  to  be  tested.  In 
this  case,  however,  the  specification  is  inadequate,  since  it  does  not 
specify  how  the  system  handles  situations  of  data  overload  or  invalid 
beacon  response  messages.  Nothing  in  this  area  should  cause  the 
symptom  "no  data  to  ROCC." 

Several  other  points  regarding  the  requirements  section  of  the  specification  are  worth 
mention. 

1.  Requirements  are  not  confined  to  Section  3.0.  Requirements  are  also 
stated  in  Sections  10.0  and  30.0.  Scattering  requirements  complicates  the 
task  of  insuring  consistency  across  requirements. 

2.  The  requirements  section  (3.0)  places  heavy  emphasis  on  design  con¬ 
straints,  i.e.,  what  is  to  occur  inside  the  double-lined  rectangle,  how  the 
product  components  are  to  be  interfaced,  and  how  the  components  are  to 
be  fabricated.  Approximately  45%  of  the  paragraphs  in  this  section  de¬ 
scribe  constraints.  This  places  the  government  in  the  business  of  system 
design  as  well  as  specification,  a  position  of  sharing  responsibility  for  the 
product's  design  that  could  complicate  warranty  enforcement. 

3.  The  maintainability  section  (3.2.4)  provides  a  definition  of  Mean  Time  To 
Repair  (MTTR)  requirements.  There  is  a  special  definition  for  software 
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MTTR:  "MTTR  for  software  shall  include  the  time  required  to  determine 
that  a  fault  was  caused  by  software  and  to  return  the  system  to  operation.* 
This  definition  defines  recovery,  not  repair,  and  is  consistent  with  the  defi¬ 
nition  in  Section  30.0.  If  that  is  all  a  warranty  covers,  it  may  give  the  con¬ 
tractor  the  opportunity  to  walk  away  from  software  defects  by  simply  pro¬ 
viding  recovery.  The  remainder  of  Section  3.2.4  details  hardware  mainte¬ 
nance  proceduralty,  but  says  nothing  about  software  maintenance. 

4.  The  refiability/availability /maintainability  section  (3.7.2.11)  for  the  Process 
and  Control  Group,  specifies  that  software  will  fail  only  10  times  per  million 
operating  hours  (about  once  every  10  years).  This  is  an  unattainable  goal 
with  today’s  technology,  and  is  impossible  to  verify  within  a  warranty 
period  acceptable  to  contractors.  There  is  no  referenced  section  in  the 
Quality  Verification  Matrix  to  indicate  how  to  validate  this  requirement 

5.  The  clutter  model  is  specified  to  the  contractor  in  Section  30.0  of  the  speci¬ 
fications.  This  leaves  the  government  completely  at  risk  If  the  model  has 
errors.  Perhaps  such  models  should  be  given  as  an  example  of  the  clutter 
model,  with  Ihe  contractor  taking  the  responsbility  of  ensuring  that  the 
model  works,  or  deriving  a  better  model.  This  will  cost  more  at  contract 
time,  but  should  produce  a  better  final  product  and  place  more  of  the  risk 
on  ihe  contractor's  shoulders. 

6.  The  specification  should  also  explain  what  to  do  if  there  are  more  than  the 
maximum  number  of  targets,  for  example: 

•  choose  the  first  hundred 

•  choose  the  hundred  most  likely  to  be  good  targets 

•  choose  the  hundred  within  a  specified  and  restrictive  detection  enve¬ 
lope 

•  choose  a  different  hundred  from  the  previous  scan 


9.2.  Quality  Assurance 

The  quality  assurance  program  for  the  FPS-1 17  system  is  outlined  in  Section  4.0  of  tee 
F PS-1 17  specification.  The  goal  of  the  quality  assurance  program,  as  stated  in  tee 
specification,  is  to  provide  a  high  degree  of  confidence  that  the  Minimally  Attended 
Radar  (MAR)  system  meets  al  the  requirements  of  Section  3.0  in  its  intended  opera¬ 
tional  setting  (paraphrased  from  Paragraph  4.1).  The  specific  quality  assurance  activi¬ 
ties  to  be  performed  are  outlined  in  Table  III  of  Section  4.0  of  tee  FPS-1 17  specification 
That  table  Indicates  that  the  activities  of  inspection,  analysis,  demonstration,  and  test  will 
be  carried  out  in  three  phases: 


•  Ptww  A  •  Development  Test  and  Evaluation  conducted  at  a  test  facility. 

•  Rhaee  B  •  Development  Test  and  Evaluation  conducted  at  a  test  range. 

•  Phase  C  -  Development  Test  and  Evaluation  conducted  at  the  King  Salmon 
operational  site. 

Table  III  identifies  specific  activities  that  are  to  be  conducted  during  each  phase.  Review 
of  this  table  indtoates  the  foliowing  two  key  points: 

1.  Quality  assurance  activities  are  emphasized  early  In  the  protect  This 
Is  the  proper  emphasis  and  is  supported  by  the  widely  known  fact  that  the 
sooner  problems  are  detected,  the  easier  and  less  expensive  they  are  to 
correct. 

2.  Teat  activity  decraaeea  In  the  final  (operational  site)  phase  of  the 
quality  assurance  program.  Since  the  goal  of  the  quality  assurance  pro¬ 
gram  is  to  provide  a  high  degree  of  confidence  that  the  system  meets  its 
needs  in  the  operational  setting,  it  seems  contradictory  to  limit  testing  at 
the  operational  site.  Early  testing  should  not  eliminate  the  need  for  testing 
at  the  later  stages  of  the  program.  Early  testing  is  aimed  at  reducing  risk 
and  decreasing  cost  It  should  not  be  used  as  a  replacement  for  thorough 
quality  assurance  activities  at  the  operational  site.  Errors  can  be  intro¬ 
duced  Into  a  product  at  any  stage  of  development,  and  there  must  be  a 
final  check  on  the  product 


9.3.  System  Acceptance  and  Deployment 

As  stated  in  Section  8.10  (page  30)  of  this  report,  the  warranty  period  ordinarily  should 
not  start  until  acceptance  following  the  completion  of  field  acceptance  tests.  Discussions 
with  DoD  personnel  indicate  that  a  production  decision  for  the  SEEK  IGLOO  FPS-117 
units  was  based  on  DT&E  and  IOT&E  tests  of  the  first  unit  at  the  King  Salmon  site  which 
has  a  benign  clutter  environment.  With  systems  like  the  FPS-117,  we  believe  decisions 
based  on  the  operation  of  one  unit  at  one  site  is  not  adequate,  and  leaves  the  govern¬ 
ment  in  a  vulnerable  position.  Our  reasons  are  listed  below. 

1 .  Radar  systems  are  eepectaily  sensitive  to  the  physical  environment 
The  Initially  deployed  system  operated  well  because  of  its  physical  loca¬ 
tion.  Other  sites  with  different  terrain  and  other  clutter  characteristics  un¬ 
covered  a  severe  problem  in  the  system’s  ability  to  handto  clutter. 

2.  Large  scale  systems  often  have  early  production  problems.  System 
manufacturing  generally  Involves  two  of  a  cony-actor's  organizations:  engi¬ 
neering  and  manufacturing.  The  first  units  installed  usually  receive  special 
attention  from  the  engineering  organization.  These  early  units,  while  not 
really  prototypes,  are  often  tuned  and  very  carefully  crafted  by  design  engi¬ 
neers.  Later  units  are  produced  by  the  manufacturing  organization  with 
decreasing  support  from  engineering.  The  manufacture  of  a  new  product 
is  subject  to  the  same  learning  curve  as  other  new  activities,  and  there  are 
bound  to  be  problems  in  units  produced  while  the  manufacturing  organi¬ 
zation  is  on  Tie  early  part  of  the  learning  curve. 


3.  Field  tests  of  each  unit  allow  an  extended  test  period.  Unless  all  units 
are  installed  simultaneously,  field  tests  of  each  unit  provide  an  extended 
test  period.  Quality  assurance  programs,  no  matter  how  well  designed,  do 
not  find  all  problems  In  the  product.  Problems  found  in  later  field  accep¬ 
tance  tests  must  be  resolved  by  the  contractor,  and  the  corrections  to  the 
problems  must  be  installed  in  the  unit  being  tested.  These  same  correc¬ 
tions  can  often  be  retrofitted  into  earlier  accepted  units  by  means  of  a  war¬ 
ranty  clause  applicable  to  the  earlier  units. 

Each  SEEK  IGLOO  FPS-117  production  radar  was  accepted  based  on  in-piant  and  on¬ 
site  (i.e..  Installation  and  Checkout)  acceptance  tests.  These  acceptance  tests  included 
a  subset  of  the  DT&E  tests.  During  Installation  and  Checkout  testing  of  the  production 
radars,  excessive  false  report  rates  were  noted  at  several  sites,  and,  on  some  oc¬ 
casions,  "not  data  to  ROCC"  failures  were  observed.  These  performance  deficiencies 
were  documented  and  cited  as  residual  tasks  at  the  time  the  radars  were  turned  over  to 
Alaskan  Air  Command.  Subsequently,  ESD  directed  the  contractor  to  correct  these 
deficiencies  at  no  cost  to  the  government.  A  two-facet  correction  program  was  initiated 
by  the  contractor  in  the  Fall  of  1986.  The  correction  program  is  still  in  process.  Initial 
results  are  very  good.  Availability  of  a  system  warranty  would  have  expedited  correction 
of  the  SEEK  IGLOO  deficiencies. 


9.4.  Operation  and  Maintenance 

Operation  and  maintenance  activities  play  an  important  role  In  warranty  enforcement. 
To  enforce  the  warranty,  the  government  may  have  to  demonstrate  that  the  most  prob¬ 
able  cause  of  a  defect  or  deficiency  is  the  contractor’s  failure  to  meet  warranty  obliga¬ 
tions.  This  implies  that  the  government  must  provide  evidence  that  the  actions  of  opera¬ 
tions  and  maintenance  personnel  most  likely  did  not  cause  the  problem.  Our  under¬ 
standing  of  how  tire  FPS-117  units  are  operated  and  maintained  suggests  the  following 
actions  may  aid  warranty  enforcement 

1 .  Physical  access  to  the  system  units  should  be  restricted.  Logs  of  who  had 
access  to  the  system  at  what  times  and  what  activities  were  performed 
should  be  maintained. 

2.  Operational  personnel  should  have  limited  access  to  functions  and  adjust¬ 
ments  that  affect  system  performance.  Internal  instrumentation  and  acti¬ 
vity  logs  could  help  demonstrate  what  adjustments,  If  any,  were  made. 

3.  Operational  personnel  should  receive  training  on  how  to  operate  the  sys¬ 
tem.  The  training  should  be  conducted  or  approved  by  the  contractor. 

4.  Maintenance  of  tie  system  should  be  provided  by  the  contractor  If  pos- 
st>ie.  Maintenance  is  especially  troublesome,  and  the  best  way  to  solve 
the  warranty  enforcement  problem  caused  by  organic  or  alternate  contrac¬ 
tor  maintenance  is  to  avoid  it  i.e.,  have  the  contractor  provide  the  mainte¬ 
nance.  If  this  is  not  possible,  the  second  best  solution  is  to  allow  the  con- 
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tractor  to  provide  or  supervise  maintenance  for  a  period  of  time  that  helps 
insure  design  problems  in  the  system  have  been  resolved.  This  solution 
eases  the  task  of  problem  isolation  and  allows  government  maintenance 
personnel  to  come  up  to  speed  over  time. 

5.  Maintenance  personnel  should  receive  training  from  or  approved  by  the 
contractor. 

6.  Detailed  maintenance  logs  should  be  maintained. 

7.  Maintenance  should  be  performed  with  contractor-approved  (or  even 
supplied)  spare  parts  and  maintenance  procedures. 
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10.  Generic  System  Warranty  Clause 

Based  on  the  considerations  we  have  addressed  in  the  foregoing  chapters  of  this  report, 

ere  have  developed  the  following  two-page  generic  system  warranty  clause. 

A.  Definitions. 

For  purposes  of  this  System  Warranty: 

1.  "System*  means  the  integrated  and  operational  product(s)  that  Is  (are)  to 
be  delivered  by  the  Contractor  under  this  oontract  A  "system*  includes  all 
of  its  elements  or  components,  including  software. 

2.  "Defect"  means  any  condition  or  characteristic  of  a  system  that  does  not 
conform  with  the  Contractor  Warranties  of  this  System  Warranty. 

3.  "Acceptance"  means  the  act  of  an  authorized  representative  of  the  Gov¬ 
ernment  by  which  the  Government  assumes  ownership  of  an  existing  sys¬ 
tem  tendered  as  partial  or  complete  performance  of  this  contract  (e.g.,  by 
execution  of  DD  Form  250  by  an  authorized  representative  of  the 
Government). 

B.  Statement  of  the  Warranties. 

The  Contractor  warrants  as  follows: 

1.  Materials  and  Workmanship.  Each  system  delivered  under  this  contract 
will  conform  to  ail  requirements  of  materials  and  workmanship  specified  in 
this  contract. 

2.  Design  and  Manufacture.  Each  system  delivered  under  this  contract  will 
conform  to  all  design  and  manufacturing  requirements  specified  in  this 
contract.  For  purposes  of  this  warranty,  "design  and  manufacturing 
requirements"  includes  the  meaning  stated  in  DFAR  Section  246.770-1. 
and  also  includes  software  design  specifications,  including  software  config¬ 
uration. 

3.  Essential  Performance.  Regardless  of  Government  initiation  of  or  partici¬ 

pation  in  developing  system  design  or  specifications,  each  system 
delivered  under  this  contract  will  conform  to  the  Essential  Performance  Re¬ 
quirements  set  forth  in  Paragraph _ of  this  contract,  as  those  Essential 

Performance  Requirements  measured,  tested,  and  verified  by  the  tests 
and  procedures  set  forth  in  Paragraph _ of  this  contract. 

C.  Notification  Requirement. 

1.  Within _ days  of  the  date  on  which  the  Contractor  first  discovers  that  a 

defect(s)  may  exist  in  a  system(s)  delivered  under  this  contract,  the  Con¬ 
tractor  shall  notify  the  Contracting  Officer  of  such  possible  defect(s),  in 
writing,  unless  the  Contracting  Officer  has  first  notified  the  Contractor,  in 
writing,  of  the  same  defect(s). 

2.  Within _ days  of  the  date  on  which  the  Government  discovers  that  a 

defect(s)  may  exist  In  any  system(s)  accepted  by  the  Government  under 
this  oontract,  toe  Contracting  Officer  shall  notify  toe  Contractor  of  such 


possble  defect(s),  in  writing,  unless  the  Contractor  has  first  notified  the 
Contracting  Officer,  in  writing,  of  the  same  defect(s). 


D.  Duration  of  the  Warranty. 

For  each  system  delivered  under  this  contract,  the  Contractor  Warranties 

stated  in  Paragraph  B.  above  shall  extend  to  all  defects  discovered  within _ 

months  from  the  date  of  acceptance  of  the  system  by  the  government. 

E.  Government  Remedies  for  Breach. 

1.  The  rights  and  remedies  of  the  Government  under  this  System  Warranty 
(a)  are  in  addition  to  any  rights  and  remedies  of  the  Government  under  any 
other  provision  of  this  contract  including,  but  not  limited  to,  the 
Government’s  rights  in  relation  to  latent  defects,  fraud,  or  gross  mistakes 
that  amount  to  fraud;  and  (b)  shall  apply  notwithstanding  inspection,  ac¬ 
ceptance,  or  any  other  clauses  or  terms  of  this  contract. 

2.  In  the  event  of  any  defect  as  defined  herein  with  respect  to  a  system 
delivered  under  this  contract,  the  Government  in  its  sole  discretion  may, 

(a)  require  the  contractor  to  take  such  action  as  may  be  necessary  to 
eliminate  the  defect,  at  no  additional  cost  to  the  Government  for  materials, 
labor,  transportation,  or  otherwise,  (b)  require  the  contractor  to  supply,  at 
no  additional  cost  to  the  Government,  all  materials  and  instructions  neces¬ 
sary  for  the  Government  to  eliminate  the  defect  and  to  pay  any  costs 
reasonably  incurred  by  the  Government  in  taking  such  action  as  may  be 
necessary  to  eliminate  the  defect,  or  (c)  equitably  reduce  the  contract 
price. 

3.  The  Government  may  elect  the  remedies  provided  in  Paragraph  E.2.(a)  or 

(b)  above  notwithstanding  any  dispute  respecting  the  existence  of  or  re¬ 
sponsibility  for  any  alleged  defect  as  defined  herein  with  respect  to  any 
system  delivered  under  this  contract;  provided  that  the  Contractor  will  not 
be  required  to  pay  costs  incurred  by  the  Government  under  Paragraph 
E.2.(b)  until  final  determination  of  the  existence  of  the  defect.  In  the  event 
that  the  alleged  defect  is  subsequently  determined  not  to  be  a  defect  sub¬ 
ject  to  this  warranty  but  the  Contractor  has  incurred  costs  under  Paragraph 
E.2.(a)  or  (b)  as  required  by  the  Government  by  virtue  of  this  Paragraph 
E.3.,  the  contract  price  under  this  contract  shall  be  equitably  adjusted. 

4.  Election  by  the  Government  of  the  remedy  provided  under  Paragraph 
E.2.(a)  or  (b)  above  shall  not  preclude  subsequent  election  of  a  different 
remedy  under  Paragraph  E.2.  if  the  defect  Is  not  successfully  eliminated 

under  the  prior  election  within _ days  of  notification  under  Paragraph 

C.  above. 

F.  Limitations  and  Exclusions  from  Warranty  Coverage. 

1.  All  implied  warranties  of  merchantability  and  fitness  for  a  particular  pur¬ 
pose  are  excluded  from  this  contract. 

2.  This  System  Warranty  shall  not  apply  to  alleged  defects  that  the  Contrac¬ 

tor  demonstrates  to  be  In  or  otherwise  attributable  to  Govomment- 
fumished  property  as  determined,  tested,  and  verified  by  the  tests  and  pro¬ 
cedures  set  forth  in  Paragraph _ of  this  contract.  Notwithstanding  this 
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Paragraph  F.2.,  a  defect  is  not  attributable  to  Government-furnished  prop¬ 
erty  if  it  is  the  result  of  installation  or  modification  of  Government-furnished 
property  by  the  Contractor  or  of  the  integration  of  Government-furnished 
property  into  any  system  delivered  under  this  contract  if  the  installation, 
modification  or  integration  of  the  Government-furnished  property  voids  or 
renders  unenforceable  any  warranties  otherwise  applicable  to  the 
Government-furnished  property. 

3.  In  any  dispute  respecting  the  application  of  Paragraph  F.2.  or  any  other 
claim  by  the  Contractor  that  a  defect  existing  in  any  system  delivered  un¬ 
der  this  contract  is  due  to  a  cause  for  which  the  Government  is  responsible 
or  which  is  otherwise  beyond  the  control  of  the  Contractor,  the  Contractor 
shall  bear  the  burden  of  demonstrating  that  the  alleged  defect  is  not  within 
the  coverage  of  this  system. 

G.  Markings. 

All  systems  delivered  under  this  contract  will  be  marked  with,  or  the  operating 
and/or  maintenance  manuals  or  instructions  accompanying  such  systems  will 
prominently  include,  notice  of  the  existence  of  this  warranty,  its  substance,  its 
duration,  and  instructions  to  notify  the  Contracting  Officer  promptly  if  the  sys¬ 
tem  is  found  to  be  defective. 


CMU/SEI-87-TR-4 


raw 


CMU/SEI-87-TR-4 


11.  Commentary  on  the  Generic  System  Warranty 
Clause 

In  this  chapter,  we  explain  the  particular  provisions  of  the  generic  system  warranty 
clause  we  have  drafted.  Our  procedure  is  to  set  forth  the  text  of  each  paragraph  of  the 
clause,  and  then  to  follow  the  text  with  our  commentary. 


11.1.  Definitions 

A.  Definitions.  For  purposes  of  this  System  Warranty: 

1.  "System"  means  the  Integrated  and  operational  product(s)  that  Is 
(are)  to  be  delivered  by  the  Contractor  under  this  contract.  A 
"system”  Includes  all  of  its  elements  or  components,  Including  soft¬ 
ware. 

2.  "Defect”  means  any  condition  or  characteristic  of  a  system  that  does 
not  conform  with  the  Contractor  Warranties  of  this  System  Warranty. 

3.  "Acceptance"  means  the  act  of  an  authorized  representative  of  the 
Government  by  which  the  Government  assumes  ownership  of  an  ex¬ 
isting  system  tendered  as  partial  or  complete  performance  of  this 
contract  (e.g.,  by  execution  of  DD  Form  250  by  an  authorized  repre¬ 
sentative  of  the  Government). 

The  definitions  provisions,  nearly  universally  included  in  more  recent  warranty  clauses, 
and  particularly  those  under  WSWA,  help  identify  the  nature  of  the  Kern  or  items  war¬ 
ranted.  the  extent  of  the  contractor's  warranty,  and  the  scope  and  duration  of  the  war¬ 
ranty,  all  as  directed  by  FAR  Section  46.706(a). 

11.1.1.  System. 

Most  clauses  identify  the  subject  of  a  warranty  as  "supplies"  (or  "services’  where 
appropriate),  but  we  have  chosen  to  make  the  subject  of  the  warranty  a  "system"  to 
clearly  establish  that  the  contractor  is  warranting  an  integrated  and  operational  whole, 
not  just  the  discrete  characteristics  or  operations  of  individual  pieces  of  the  system.  In 
individual  applications  it  may  be  desirable  to  more  specifically  identify  the  particular  sys¬ 
tem  being  warranted.  If  software  coverage  is  intended,  the  clause  should  dearly  indude 
software  as  a  warranted  element  of  the  system  since  software  is  often  exduded  from 
warranty  coverage. 
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11.1.2.  Defect. 

A  "defect"  is  most  commonly  defined  in  existing  warranties  in  terms  of  any  deviation  from 
contractual  requirements.  That  definition  is  too  broad  for  purposes  of  warranty  coverage 
under  WSWA.  which  mandates  warranties  of  essential  performance  requirements  only, 
10  U.S.C.  Section  2403(b)(3),  leaving  outside  the  warranty  those  contractually  specified 
"operating  capabilities  or  maintenance  and  reliability  characteristics  of  the  system"  that 
are  not  "necessary  for  the  system  to  fulfill  the  military  requirement  for  which  the  system 
is  designed."  Id.  Section  2403(a)(4).8  It  is  possible,  of  course,  that  in  a  given  procure¬ 
ment  all  performance  requirements  might  be  "essential."  That  is  probably  not  the  usual 
case,  however,  particularly  since  the  cost  and  administrative  difficulty  of  a  warranty  will 
likely  increase  in  relation  to  the  scope  of  warranty  coverage.  Thus  a  defect  for  our  pur¬ 
poses  should  be  defined  in  terms  of  deviations  from  the  contractor’s  warranted  under¬ 
taking,  not  from  any  and  all  contractual  requirements.  Such  a  definition  both  limits  the 
warranty  and,  when  essential  performance  requirements  are  warranted,  makes  clear 
that  any  deviation  from  those  performance  requirements  comes  within  the  definition  of  a 
"defect"  for  which  the  contractor  is  liable  under  the  warranty. 

The  definition  does  not  distinguish  between  latent  defects  and  patent  defects  for  the 
reason  that  there  is  no  difference  between  the  two  for  purposes  of  warranty  protection. 
Latent  and  patent  defects  must  be  distinguished  for  purposes  of  acceptance,  but  not  for 
warranty  —  at  least  where  the  warranty  clause  is  properly  drafted.  Thus,  acceptance  is 
ordinarily  conclusive  as  to  patent  defects  —  defects  that  are  discoverable  by  ordinary  or 
reasonable  inspection  or  testing  —  and  absent  warranty  protection  the  government  gen¬ 
erally  has  no  post-acceptance  remedy  for  such  defects.  See,  e.g.,  California  Power  Sys¬ 
tems,  Inc.,  GSBCA  No.  7462,  86-1  BCA  Paragraph  18,598  (1985);  Harold  Bailey  Paint¬ 
ing  Co.,  ASBCA  No.  28,443,  84-1  BCA  Paragraph  17,043  (1983);  Solid  State  Electronics 
Corp.,  ASBCA  No.  23041,  80-2  BCA  Paragraph  14,702  (1980).  Where,  as  in  this 
generic  clause,  however,  the  warranty  clause  is  drafted  to  apply  notwithstanding  previ¬ 
ous  inspection  or  acceptance,  see  Paragraph  E.1.(b),  then  the  warranty  survives  accep¬ 
tance  and  applies  even  to  patent  defects  discovered  within  the  warranty  period.  See, 
e.g..  Standard  Blackboard  and  School  Supply  Co.,  GSBCA  No.  7403  and  7255,  86-1 
BCA  Paragraph  18,712  (1985);  ZA.N.  Co.,  ASBCA  No.  75488,  86-1  BCA  Paragraph 
18,612  (1985).9  In  such  cases,  the  warranty  is  generally  the  only  post-acceptance  rem¬ 
edy  available  for  patent  defects.  Where,  on  the  other  hand,  defects  are  latent  —  that  is, 
not  discoverable  by  ordinary  or  reasonable  inspection  or  testing  at  the  time  of  accep¬ 
tance  —  the  government  can  usually  require  repair  or  replacement  of  the  defective  prod¬ 
uct  even  after  acceptance  with  or  without  a  separate  warranty.  Coral  Petroleum,  Inc., 
ASBCA  No.  27,888,  86-1  BCA  Paragraph  18,533  (1985);  Teller  Environmental  Sys¬ 
tems,  Inc.,  ASBCA  No.  25,550,  85-2  BCA  Paragraph  18,025  (1985);  American  Trans- 
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Coll  Corp.,  ASBCA  No.  27037,  85-1  BCA  Paragraph  17,864  (1985).  In  such  cases  of 
latent  defects,  the  warranty  is  simply  an  alternative  remedy  to  remedies  otherwise  al¬ 
ready  available.  See  Paragraph  E.1.(a). 

11.1.3.  Acceptance. 

Acceptance  is  the  event  that  in  most  cases  will  trigger  the  period  of  warranty  coverage. 
Up  to  that  point,  the  government’s  right  to  require  correction  of  any  identified  deviations 
from  contractual  requirements  are  independent  of  the  warranty.  The  definition  of  accep¬ 
tance  here  expands  on,  but  is  consistent  with,  FAR  Section  46.101. 

11.2.  Statement  of  the  Warranties 

B.  Contractor  Warranty.  The  Contractor  warrants  as  follows: 

1.  Material  and  Workmanship.  Each  system  delivered  under  this  con¬ 
tract  will  conform  to  all  requirements  of  materials  and  workmanship 
specified  In  this  contract 

2.  Design  and  Manufacture.  Each  system  delivered  under  this  contract 
will  conform  to  all  design  and  manufacturing  requirements  specified 
In  this  contract.  For  purposes  of  this  warranty,  "design  and  manu¬ 
facturing  requirements"  Includes  the  meaning  stated  In  DFAR  Sec¬ 
tion  246.770-1,  and  also  Includes  software  design  specifications,  In¬ 
cluding  software  configurations. 

3.  Essential  Performance.  Regardless  of  Government  Initiation  of  or 

participation  In  developing  system  design  or  specifications,  each 
system  delivered  under  this  contract  will  conform  to  the  Essential 
Performance  Requirements  set  forth  In  Paragraoh _ of  this  con¬ 

tract,  as  those  Essential  Performance  Requirements  measured, 
tested,  and  verified  by  the  tests  and  procedures  set  forth  In 
Paragraph _ of  this  contract. 

11.2.1.  General  Background. 

Paragraph  B  states  the  characteristics  of  the  system  that  the  contractor  warrants  and 
further  defines  the  extent  of  the  warranty,  consistent  with  the  instructions  of  FAR  Section 
46.706(a)(1)  &  (2).  The  three  elements  of  the  generic  warranty  —  (1)  materials  and 
workmanship.  (2)  design  and  manufacture,  and  (3)  essential  performance,  —  are  those 
generally  required  by  WSWA.  10  U.S.C.  Section  2403(b)(1)-(3).  Warranties  of  materials 
and  workmanship  have  long  been  Included  in  government  contracts.  WSWA's  warranty 
of  conformity  with  design  and  manufacture  requirements  is  fundamentally  a  traditional 
•build  to  print"  warranty.  DFAR  Section  246.770-1,  cross-referenced  in  Paragraph  B.2. 
of  the  generic  clause,  defines  "design  and  manufacturing  requirements"  as  "structural 
and  engineering  plans  and  manufacturing  particulars,  Including  precise  measurements, 
tolerances,  materials  and  finished  product  tests  for  the  weapon  system  being  produced." 


In  view  of  the  software-oriented  nature  of  our  task,  we  have  expanded  the  definition  of 
design  and  manufacture  requirements  to  include  software  requirements,  including  soft¬ 
ware  configuration  specifications.  For  example,  the  contract  might  specify  that  each 
computer  program  must  consist  of  less  than  1 00  lines  of  source  statements,  excluding 
comments.  Under  the  generic  clause  as  drafted  here,  the  contracts  would  warrant  pro¬ 
duction  conformity  with  that  specification  just  as  with  the  hardware  specifications  to 
which  "design  and  manufacture’  requirements  commonly  apply.  This  expanded  warran¬ 
ty  coverage  is  consistent  with  WSWA's  directive  that  "[njothing  in  this  section  prohibits 
the  head  of  the  agency  concerned  from  . . .  using  written  guarantees  to  a  greater  extent 
than  required  by  this  section,  including  guarantees  that  exceed  those"  strictly  specified  in 
the  Act. 

11.2.2.  The  Warranty  of  Essential  Performance  Requirements. 

Paragraph  B.3.,  Essential  Performance,  is  the  heart  of  the  warranty  as  far  as  software 
and  system  performance  is  concerned.  As  noted  in  Chapter  5,  the  object  here  is  to 
define  essential  performance  requirements  in  terms  of  objective  and  carefully  defined 
essential  operating,  maintenance,  and  reliability  characteristics,  see  FAR  Section 
246.770-1,  that  can  be  measured  and  verified  by  means  of  tests  and  procedures  to 
which  the  contractor  has  agreed  in  the  contract.  Under  this  approach,  if  the  system  fails 
the  tests  that  define  conformity  with  the  contract’s  essential  performance  requirements, 
then  the  system  is  defective.  Much  of  the  enforcement  problem  In  previous  performance 
warranties  has  been  a  failure  to  articulate  standards  against  which  system  performance 
can  be  measured,  for  it  is  nearly  impossible  to  prove  a  breach  of  standards  or  require¬ 
ments  that  are  not  defined  or  measurable.  Drafting  performance  requirements  is  a  tech¬ 
nical,  not  a  legal,  exercise  and  can  only  be  performed  in  the  context  of  individual  sys¬ 
tems.  The  generic  clause  thus  cross-references  to  the  contract’s  essential  performance 
requirements  and  to  the  means  to  be  used  in  establishing  conformity  with  those  require¬ 
ments. 

11.2.3.  The  Effect  of  Government  Participation  in  System  Design. 

In  view  of  a  general  reluctance  to  make  contractors  responsible  for  failures  due  to  faulty 
government  design.  cf.,  e.g.,  S&E  Contractors,  Inc.,  ASBCA  11044,  61-1  BCA 
Paragraph  6175  (1967);  R.H.  Fulton,  Contractor,  IBCA  769-3-69,  71-1  BCA  Paragraph 
B674  (1971),  Paragraph  B.3.  of  the  generic  clause  also  makes  explicit  that  the  system 
performance  warranty  applies  despite  government  initiation  of  or  participation  in  system 
design.  In  the  ordinary  course,  “(ijf  the  Government  specifies  the  design  of  the  end  item 
...  the  contractor's  obligations  for  correction  of  defects  shall  usually  be  limited  to  defects 
In  material  and  workmanship  or  failure  to  conform  to  specifications.’  FAR  Section 
46.706(b)(1)(ii).  The  point  of  a  performance  warranty  as  mandated  by  WSWA,  however, 
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is  to  force  the  contractor  to  assume  responsibility  for  determining  whether  the  design  of 
the  system  —  whether  initially  developed  by  the  contractor  or  the  government  —  will 
result  in  a  product  that  can  satisfy  the  contract's  essential  performance  requirements. 
The  contractor,  in  other  words,  assumes  a  responsibility  for  proposing  alternate  designs 
if  the  existing  design  will  not  work. 

Thus,  the  mere  fact  that  the  government  is  a  player  in  system  design  should  not  inval¬ 
idate  the  performance  warranty.  Even  so,  WSWA’s  legislative  history  and  the  DFAR 
provisions  implementing  WSWA  both  recognize  that  there  may  come  a  point  where  the 
government  so  dictates  the  system  design  that  it  would  be  inequitable  to  obligate  the 
contractor  to  warrant  system  performance,  or  at  least  to  warrant  those  aspects  of  system 
performance  directly  affected  by  the  government’s  design.10 

Design  specifications,  of  course,  may  change  during  the  period  of  contract  performance. 
Indeed.  WSWA’s  approach  to  essential  performance  warranties  encourages  such 
changes,  if  necessary,  in  order  to  make  the  warranted  system  capable  of  achieving  its 
essential  performance  requirements.  Design  changes  that  do  not,  or  do  not  necessarily, 
adversely  affect  the  capabilities  of  the  system  should  have  no  effect  on  the  essential 
performance  warranty  (although,  of  course,  they  would  change  the  specifications  to 
which  the  system  must  conform  under  the  design  and  manufacture  warranty).11 

11.2.4.  A  Possible  Warranty  Exception  for  Initial  Production. 

The  essential  performance  warranty  of  Paragraph  B.3.  as  drafted  applies  by  its  terms  to 
every  system  delivered  under  the  contract.  WSWA,  however,  would  routinely  require  an 
essential  performance  warranty  only  for  weapons  systems  ‘in  mature  full  scale 
production."  10  U.S.C.  Section  2403(f).  Weapons  systems  are  'in  mature  full  scale 
production"  under  WSWA  "after  the  manufacture  of  the  first  one-tenth  of  the  eventual 
total  production  or  the  initial  production  quantity  of  such  system,  whichever  is  less."  Id. 
Section  2403(a)(6).  This  WSWA  limitation  to  systems  in  mature  full  scale  production 
was  intended  to  provide  contractors  and  the  government  with  the  opportunity,  in  light  of 
actual  experience,  to  make  any  necessary  modifications  to  system  design  or  other  con¬ 
tractual  requirements  before  the  contractor’s  warranty  obligations  attached,  it  was 
hoped  that  by  exempting  initial  production  from  warranty  coverage,  the  warranty  would 
be  less  costly  and  would  avoid  negotiated  downgrades  of  performance  requirements. 
See  generally,  S.  Rep.  No.  98-500,  supra,  248-49. 

We  did  not  limit  the  generic  clause  to  mature  full-scale  production  because  it  seemed  to 
us  that  such  a  limitation  might  be  undesirable  where  only  a  few  systems  are  being  pro¬ 
duced  under  a  contract,  as,  for  example,  under  the  North  Warning  procurement.  Indeed, 
because  the  various  North  Warning  installations  all  must  work  as  part  of  a  larger  system. 
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it  may  be  that  in  such  cases  the  single  larger  system,  not  each  individual  unit  of  the 
larger  system,  may  be  the  subject  of  the  warranty.  Even  if  "system*  were  not  defined  so 
expansively,  it  may  be  that  such  necessary  system  integration  Itself  provides  a  reason 
for  warranting  every  unit  without  excluding  initial  production.12 

11.3.  Notification  Requirement 

C.  Notification. 

1.  Within _ days  of  the  date  on  which  the  Contractor  first  discovers 

that  a  defect(s)  may  exist  In  a  system(s)  delivered  under  this  con¬ 
tract,  the  Contractor  shall  notify  the  Contracting  Officer  of  such  pos¬ 
sible  defect (s),  In  writing,  unless  the  Contracting  Officer  has  first  no¬ 
tified  the  Contractor,  In  writing,  of  the  same  defect(s). 

2.  Within _ days  of  the  date  on  which  the  Government  discovers  that 

a  defect(s)  may  exist  In  any  system(s)  accepted  by  the  Government 
under  this  contract,  the  Contracting  Officer  shall  notify  the  Contrac¬ 
tor  of  such  possible  defect(s),  In  writing,  unless  the  Contractor  has 
first  notified  the  Contracting  Officer,  In  writing,  of  the  same  defect(s). 

11.3.1.  The  Purpose  of  Notification. 

FAR  Section  46.4706(b)(4)  requires  that  a  notice  period  be  established  for  notification  to 
the  contractor  of  discovery  of  a  defect  The  notice  period  is  to  be  "reasonable"  consid¬ 
ering  the  time  necessary  for  the  government  to  discover  the  defects,  the  time  reasonably 
required  for  the  government  to  take  necessary  administrative  steps  and  make  a  timely 
report  of  discovery  of  the  defects,  and  the  time  required  to  discover  and  report  any 
defective  replacements.  Those  factors  will  vary  from  system  to  system  and  so  will  re¬ 
quire  tailoring  the  clause  for  each  procurement.  The  objective  in  any  case  is  to  make 
sure  that  the  government  has  adequate  time  to  give  notice.  Further,  it  seems  sensible  to 
add  a  reciprocal  obligation  of  the  contractor  to  notify  the  government  of  any  defects  it 
may  discover  after  delivery.  The  contractor  should  not  be  permitted  to  remain  silent 
about  known  defects  in  an  attempt  to  avoid  its  warranty  obligations. 

11.3.2.  Tha  Need  for  Cato  by  Case  Tailoring. 

Individual  systems  may  make  desirable  further  tailoring  of  the  notification  provision  to 
provide  detail  respecting  such  matters  as  the  content  of  the  notification,  contractor  re¬ 
sponse  obligations,  or  contractor  investigation  obligations.  For  example,  in  some  cir¬ 
cumstances  it  may  be  desirable,  before  triggering  repair  or  replacement  obligations,  to 
provide  (1)  that  the  government  will  provide  a  description  of  the  defect  or  its  effects,  (2) 
that  the  contractor  will  then  investigate  the  defect  and  provide  a  written  response  to  the 
notification  proposing  a  course  of  action,  and  (3)  that  the  government  may  then  elect  a 
remedy  following  the  contractor's  response.  In  some  circumstances  it  may  be  desirable 
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also  to  indude  a  second  more  immediate  notification  obligation  of  the  contractor  where 
the  defect  discovered  —  or  perhaps  even  only  reasonably  suspected  —  by  the  contrac¬ 
tor  is  such  as  would  endanger  person  or  property,  including  defects  that  could  cause 
damage  to  the  system  if  unremedied. 

11.4.  Duration  of  the  Warranty 

D.  Duration. 

For  such  system  delivered  under  this  contract,  the  Contractor  War¬ 
ranties  stated  In  Paragraph  B.  above  shall  extend  to  all  defects  dis¬ 
covered  within _ months  from  the  date  of  acceptance  of  the  system  by 

the  government. 

FAR  Section  46.706(b)(3)  requires  that  the  duration  or  time  period  of  the  warranty  be 
dearly  specified  in  the  warranty.  The  regulations  further  provide  that  the  warranty  period 
for  patent  defects  should  not  extend  beyond  a  reasonable  time  after  acceptance,  and 
that  the  warranty  period  should  be  set  in  view  of  such  factors  as  the  estimated  useful  life 
of  the  item,  the  nature  of  the  item,  and  trade  practice.  These  factors  all  require  in¬ 
dividually  tailored  warranty  periods.  Individual  circumstances  also  may  make  it  sensible 
to  apply  different  warranty  periods  to  each  of  the  three  different  WSWA  warranties,  or  to 
extend  the  warranty  period  if  full  field  testing  of  the  system  cannot  be  completed  before 
acceptance.  The  government  might  also  consider  in  individual  cases  restarting,  or  pro¬ 
viding  for  an  extension  of,  the  warranty  after  repair  or  replacement  of  the  defective  sys¬ 
tem.  Such  extensions  of  the  warranty  period  might  be  especially  appropriate  where  soft¬ 
ware  repairs  result  in  software  enhancements.  See  Section  8.8,  (page  30).  In  such 
cases  a  "new*  system  has  been  provided,  and  the  considerations  that  led  to  requiring  a 
warranty  in  the  first  place  are  at  least  in  some  measure  reimplicated  when  system  en¬ 
hancements  are  added. 

11.5.  Government  Remedies  for  Breach 

E.  Remedies. 

1.  The  rights  and  remedies  of  the  Government  under  this  System  War¬ 
ranty  (a)  are  in  addition  to  any  rights  and  remedies  of  the  Govern¬ 
ment  under  any  other  provision  of  this  contract,  including,  but  not 
limited  to,  the  Government’s  rights  In  relation  to  latent  defects,  fraud, 
or  gross  mistakes  that  amount  to  fraud;  and  (b)  shall  apply  notwith¬ 
standing  Inspection,  acceptance,  or  any  other  clauses  or  terms  of 
this  contract. 

2.  In  the  event  of  any  defect  as  defined  herein  with  respect  to  a  system 
delivered  under  this  contract,  the  Government  In  Its  sole  discretion 
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•ary  to  eliminate  tho  defect,  at  no  additional  coat  to  the  Government 
tor  material e,  labor,  tranaportatlon,  or  otherwlae,  (b)  require  the  con¬ 
tractor  to  aupply,  at  no  additional  coat  to  the  Government,  all 
mate ri ale  and  Inatructlone  neceaaary  for  the  Government  to  eliminate 
the  defect  and  to  pay  any  coata  reaaonably  Incurred  by  the  Govern¬ 
ment  In  taking  auch  action  aa  may  be  neceaaary  to  eliminate  the 
defect,  or  (c)  equitably  reduce  the  contract  price. 

3.  The  Government  may  elect  the  remedlea  provided  In  Paragraph 
E.2.(a)  or  (b)  above  notwlthatandlng  any  dlapute  reapectlng  the  exle- 
tence  of  or  reaponalblllty  for  any  alleged  defect  aa  defined  herein 
with  reepect  to  any  ayatem  delivered  under  thle  contract;  provided 
that  the  Contractor  will  not  be  required  to  pay  coata  Incurred  by  the 
Government  under  Paragraph  E.2.(b)  until  final  determination  of  the 
exlatence  of  the  defect.  In  the  event  that  the  alleged  defect  la  aub- 
aequently  determined  not  to  be  a  defect  subject  to  thla  warranty  but 
the  Contractor  haa  Incurred  coata  under  Paragraph  E.2.(a)  or  (b)  aa 
required  by  the  Government  by  virtue  of  thla  Paragraph  E.3.,  the  con¬ 
tract  price  under  thla  contract  ahall  be  equitably  adjuated. 

4.  Election  by  the  Government  of  the  remedy  provided  under  Paragraph 

E.2.(a)  or  (b)  above  ahall  not  preclude  subsequent  election  of  a  differ¬ 
ent  remedy  under  Paragraph  E.2.  H  the  defect  la  not  aucceaafully 
eliminated  under  the  prior  election  within _ daye  of  notification  un¬ 

der  Paragraph  C.  above. 

11.5.1.  General  Regulatory  Background. 

FAR  Section  46.706(c)(2)  &  (3)  requires  that  a  warranty  clause  state  the  contractor's 
obligations  to  the  government  for  breach  of  warranty  and  the  specific  remedies  available 
to  the  government  for  breach.  Paragraph  E  of  the  generic  system  warranty  Is  designed 
to  conform  to  that  requirement.  Much  of  Paragraph  E.l.  and  2.  is  routinely  grounded  in 
existing  statutory  and  regulatory  requirements. 

Paragraph  E.1.  complies  with  the  requirements  of  FAR  Section  46.705(b)  &  (c).13  which, 
broadly  stated,  are  intended  to  assure  that  the  government’s  warranty  protections  are  in 
addition  to,  and  not  instead  of,  Sny  other  rights  the  government  has  under  its  contracts. 
Paragraph  E.2.  cumulates  the  various  remedies  established  under  FAR  Section 
46.706(b)(2).  It  is  drafted  to  assure  that  the  remedies  provided  will  be  without  cost 
(additional  to  the  cost  of  including  the  warranty  in  the  first  place)  to  the  government. 
WSWA  by  its  term 8  provides  only  for  the  remedies  provided  in  E.2.(a)  &  (b),  but  the 
implementing  regulations  provide  for  the  equitable  adjustment  remedy  provided  in 
E.2.(c)  as  well.14 
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11.5.2.  Government  Remedies  in  the  Event  of  Disputed  Defects. 

Paragraph  E.3.  permits  the  government  to  require  the  contractor  to  eliminate  defects  in 
advance  of  final  determination  of  contractor  liability  under  the  warranty  if  there  is  a  dis¬ 
pute  with  respect  to  the  existence  of  or  responsibility  for  a  defect.  The  government  may 
also  take  action  to  eliminate  the  defects  itself  before  final  resolution  of  such  a  dispute, 
and.  pursuant  to  Paragraph  E.2.(b),  may  require  the  contractor  to  supply  materials  and 
instructions.  Such  protections  seem  appropriate  in  the  context  of  critical  defense  sys¬ 
tems,  and  are  wholly  consistent  with  ordinary  disputes  procedures  where  continued  con¬ 
tractor  performance  is  required  notwithstanding  the  existence  of  a  dispute.  The  contrac¬ 
tor  is  entitled  to  an  equitable  adjustment  if  the  contractor  incurs  costs  for  which  it  is 
finally  determined  that  the  contractor  was  not  liable  under  the  terms  of  the  warranty. 

11.5.3.  Alternate  Remedies  In  the  Event  of  Incurable  Defects. 

There  may  be  occasions  when  neither  the  contractor  nor  the  government  are  able  to 
remedy  a  discovered  defect  Paragraph  E.4.  permits  the  government,  within  a  period  of 
time  to  be  fixed  in  the  context  of  particular  systems  and  procurements,  to  elect  a  differ¬ 
ent  remedy  if  its  initial  election  proves  unsatisfactory.  This  paragraph  does  not  require 
the  government  to  elect  an  alternate  remedy  upon  expiration  of  the  stated  time,  but  al¬ 
lows  the  government  to  do  so  at  its  option  any  time  thereafter. 


11.6.  Limitations  of  and  Exclusions  from  Warranty  Coverage 

F.  Limitations  and  Exclusions. 

1.  All  Implied  warranties  of  merchantability  and  fitness  for  a  particular 
purpose  are  excluded  from  this  contract. 

2.  This  System  Warranty  shall  not  apply  to  alleged  defects  that  the  Con¬ 

tractor  demonstrates  to  be  In  or  otherwise  attributable  to 
Government-furnished  property  as  determined,  tested,  and  verified 
by  the  testa  and  procedures  set  forth  In  Paragraph _ of  this  con¬ 

tract.  Notwithstanding  this  Paragraph  F.2.,  a  defect  Is  not  attributable 
to  Government-furnished  property  If  It  Is  the  result  of  Installation  or 
modification  of  Government-furnished  property  by  the  Contractor  or 
of  the  Integration  of  Government-furnished  property  Into  any  system 
delivered  under  this  contract  If  the  Installation,  modification  or  Inte¬ 
gration  of  the  Government-furnished  property  voids  or  renders  un¬ 
enforceable  any  warranties  otherwise  applicable  to  the  Government- 
furnished  property. 

3.  In  any  dispute  respecting  the  application  of  Paragraph  F.2.  or  any 
other  claim  by  the  Contractor  that  a  defect  existing  In  any  system 
delivered  under  this  contract  Is  due  to  a  cause  for  which  the  Govern¬ 
ment  Is  responsible  or  which  Is  otherwise  beyond  the  control  of  the 
Contractor,  the  Contractor  shall  bear  the  burden  of  demonstrating 
that  the  alleged  defect  Is  not  within  the  coverage  of  this  system  war¬ 
ranty. 
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11.6.1.  The  Purpose  and  Scope  of  Possible  Limitations  and 
Exclusions. 

Paragraph  F.I.,  which  excludes  implied  warranties  of  merchantability  and  fitness  for  a 
particular  purpose,  conforms  with  the  requirements  of  FAR  Section  46.706(b)(i)(iii). 
Other  limitations  or  exclusions  might  be  appropriate  or  necessary  in  specific  situations  in 
order  to  obtain  reasonably  priced  warranty  coverage.  WSWA,  10  U.S.C.  Section 
2403(g)(1),  provides  that  nothing  in  WSWA  prohibits  the  head  of  a  procuring  agency 
from  ‘negotiating  the  specific  details  of  a  guarantee,  Including  reasonable  exclusions, 
limitations  and  time  duration,  so  long  as  the  negotiated  guarantee  Is  consistent  with  the 
general  requirements  of  this  section."  DFAR  Section  246.770-3  amplifies  this  authoriza¬ 
tion  by  providing  that  "Contracting  officers  may  exclude  from  the  terms  of  the  warranty 
certain  defects  for  specified  supplies  (exclusions)  and  may  limit  the  contractor's  liability 
under  the  terms  of  the  warranty  (limitations),  as  appropriate,  if  necessary  to  derive  a 
cost-effective  warranty  in  light  of  the  technical  risk,  contractor  financial  risk  or  other  pro¬ 
gram  uncertainties."  Thus,  in  order  to  obtain  cost  effective  warranties,  the  warranty 
might  exclude  such  things  as  defects  arising  out  of  normal  wear  and  tear,  combat,  or 
misuse  or  improper  maintenance  by  the  government.15  It  also  might  exclude  liability  for 
consequential  damages,  damage  to  property,  or  loss,  damage,  or  injury  to  third  parties, 
or  might  limit  the  contractor's  liability  to  a  fixed  "cap."  set  either  in  terms  of  an  absolute 
dollar  amount  or  a  percentage  of  the  contract  price. 

11.6.2.  Exclusion  of  Govemment-Fumiahed  Equipment. 

Paragraphs  F.2.  and  F.3.  are,  with  the  exception  of  Paragraph  B.3.  which  relies  for  its 
effectiveness  on  carefully  crafted  essential  performance  requirements  and  verification 
procedures,  probably  the  most  problematic  paragraphs  of  the  warranty  clause.  WSWA 
directly  prohibits  requiring  warranties  from  a  prime  contractor  lor  a  weapon  system,  or 
for  a  component  of  a  weapon  system,  that  is  furnished  by  the  United  States  to  the 
contractor."  10  U.S.C.  Section  2403(c).  This  exclusion,  however,  is  not  absolute  The 
warranty  may  require  that  "components  of  a  weapon  system  furnished  by  the  United 
States  to  a  contractor  be  property  installed  so  as  not  to  Invalidate  any  warranty  or 
guarantee  provided  by  the  manufacturer  of  such  component  to  the  United  States."  fcf. 
Section  2403(g)(2).  Moreover,  DFAR  Section  246.770.5  provides  that  contractors  may 
be  required  to  warrant  defects  in  installation  or  any  modifications  made  to  the  property 
by  the  prime  contractor.  Paragraph  F.2.  is  designed  to  make  the  exclusion  for 
government-furnished  equipment  (GFE)  as  narrow  as  possible  consistent  with  these 
statutory  and  regulatory  authorities. 
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11.6.3.  The  Government’s  Burden  of  Proof. 

As  we  explained  in  Section  4.1 .2  (page  1 1 ),  the  problem  with  even  a  narrow  exclusion  is 
that  in  most  cases  taken  before  boards  of  contract  appeals  the  rule  applied  has  been 
that  as  part  of  its  burden  of  proof  the  government  must  prove,  not  only  the  existence  of  a 
defect,  but  also  that  the  defect  is  the  contractor's  responsibility  within  the  terms  of  the 
warranty  —  which  can  involve  proving  that  the  alleged  defect  was  not  attributable  to  any 
cause  for  which  the  government  is  responsible.  Consistent  with  the  considerations  ad¬ 
dressed  in  Section  4.1.2,  the  GFE  exclusion  in  the  generic  clause  has  been  drafted  in 
such  a  way  as  to  maximize  the  government's  chances  of  shifting  to  the  contractor  the 
burden  of  proof  with  respect  to  GFE  defects,  and  minimizing  the  government's  burden  if 
the  burden  cannot  be  shifted.  This  has  been  done  by  (1)  setting  the  exclusion  in  a  sepa¬ 
rate  clause,  and  not  as  an  exception  made  part  of  the  Paragraph  B.3.  contractor  war¬ 
ranty  of  essential  performance;  (2)  phrasing  the  exception  In  terms  of  contractor  demon¬ 
stration  of  GFE  fault;  (4)  explicitly  providing  that  the  contractor  bears  the  burden  of  proof; 
and  (5)  drafting  the  exclusion  in  terms  of  tests  and  procedures  that  demonstrate  the  re¬ 
sponsibility  or  nonresponsibility  of  GFE  for  the  system  defect. 

11.7.  Markings 

G.  Markings. 

All  systems  delivered  under  this  contract  will  be  marked  with,  or  the 
operating  and/or  maintenance  manuals  or  Instructions  accompanying 
auch  systems  will  prominently  Include,  notice  of  the  existence  of  this 
warranty,  Its  substance,  Its  duration,  and  Instructions  to  notify  the  Con¬ 
tracting  Officer  promptly  If  the  system  is  found  to  be  defective. 

This  paragraph  is  intended  to  conform  with  the  requirements  of  FAR  Section 
46.706(b)(5)  Where  large  or  unattended  systems  are  involved,  a  marking  on  the  sys 
tern  itself  may  not  be  effective  as  notice  to  the  user  cf  the  existence  of  the  warranty  and 
of  the  need  to  act  in  compliance  with  that  warranty  to  protect  the  government's  rights 
Notice  to  the  user  by  other  means,  such  as  through  operating  or  maintenance  manuals, 
may  be  more  effective. 
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12.  Conclusions 


Our  investigation  of  the  motivation  behind  the  request  for  a  software  warranty  clause 
indicated  that  a  software  warranty  clause  alone  would  not  solve  the  basic  problems  that 
led  to  the  task  in  the  first  place.  The  Software  Engineering  Institute  discovered  that  the 
enforcement  problem  was  not  so  much  associated  with  the  legal  framework  of  the 
various  warranty  clauses,  but  with  the  tack  of  meaningful  specifications  and  tests  de¬ 
signed  to  demonstrate  system  defects  that  trigger  warranty  coverage  of  the  system  as  a 
whole.  The  scope  of  the  task  was  therefore  broadened  to  address  technical  and  admin¬ 
istrative  issues  associated  with  the  application  and  enforcement  of  an  inclusive  system 
warranty  that  covers  software  as  part  of  the  warranted  system. 

Our  approach  to  relieving  the  problems  of  system  failure,  described  in  the  body  of  this 
report,  is  to  write  a  more  enforceable  warranty  clause  and  to  describe  legal,  technical, 
and  administrative  Issues  that  support  warranty  enforcement.  The  objective  is  to  ease 
the  government's  burden  of  proving  the  existence  of  a  defect  for  which  the  warranty 
clause  provides  a  remedy.  The  key  to  satisfying  that  objective  is  to  develop  technical 
tests  and  specifications  that  provide  objective  and  demonstrable  standards  against 
which  a  claim  for  breach  of  warranty  can  be  measured. 

Our  specific  recommendations  are  summarized  below. 

1.  To  ease  the  burden  the  government  bears  to  prove  a  breach  of  warranty, 
the  generic  warranty  should  cover  the  failure  of  a  delivered  system  as  a 
whole,  including,  but  not  limited  to,  its  software,  to  satisfy  clear  and  meas¬ 
urable  essential  performance  requirements  for  the  system.  Essential  per¬ 
formance  requirements  must  be  based  on  a  clear  distinction  between  the 
warranted  product  and  other  components  in  the  environment. 

2.  Conditions  for  establishing  breach  of  warranty  should  be  described  in 
terms  of  analysis  of  recorded  symptoms  and  diagnostic  results.  The  test 
methods  to  determine  breach  should  be  described  in  the  specifications. 

3.  Through  careful  drafting  and  aggressive  litigation  techniques,  the  govern¬ 
ment  has  a  good  chance  of  changing  the  currently  accepted  legal  stan¬ 
dard,  and  of  shifting  to  the  contractor  the  burden  of  proving  that  system 
defects  are  attributable  to  government-furnished  equipment.  Even  if  the 
burden  cannot  be  shifted,  however,  the  government’s  burden  of  proof  can 
be  minimized  by  developing  tests  and  procedures  that  will  isolate  defects 
in  government-furnished  equipment. 

4.  To  provide  maximum  applicability  and  enforceability,  the  generic  clause 
should  be  modeled  after  the  Weapon  Systems  Warranty  Act,  and  must  be 
carefully  tailored  on  a  case  by  case  basis. 

5.  Government  procurement  practices  contribute  substantially  to  existing 
problems.  If  it  is  to  reap  the  benefit  of  improved  legal  and  technical  war¬ 
ranty  considerations,  the  government  must  improve  such  practices. 


6.  The  quality  of  the  product  is  heavily  dependent  on  the  specifications  de¬ 
scribing  the  product  and  the  clear  description  of  the  critical  functions  to  be 
performed.  The  success  of  a  product  and  the  applicability  of  a  warranty 
depend  on  a  well  crafted  specification. 

7.  Warranties  are  not  costless,  and  contractors  can  be  expected  to  price  war¬ 
ranties  even  higher  as  their  exposure  to  warranty  liability  increases 
through  increased  warranty  scope,  remedies,  and  enforceability.  There 
are  remedies  other  than  warranties  which  also  would  improve  the  de¬ 
ployed  products,  so,  in  each  individual  case,  the  costs  and  benefits  of  the 
warranty  must  be  balanced  against  the  costs  and  benefits  of  other  ap¬ 
plicable  remedies. 
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Appendix  I.  Pertinent  Abbreviations  and  Acronyms 


AFSC 

Air  Force  Systems  Command 

ASBCA 

Armed  Services  Board  of  Contract  Appeals 

BCA 

Board  of  Contract  Appeals 

DFAR 

Defense  Federal  Acquisition  Regulations  Supplements 

DoD 

Department  of  Defense 

DOT 

Department  of  Transportation 

ESD 

Electronic  Systems  Division 

FAR 

Federal  Acquisition  Regulations 

FAT 

Factory  Acceptance  Test 

FIAT 

Field  Acceptance  Test 

GFE 

government-furnished  equipment 

GSBCA 

Government  Services  Board  of  Contract  Appeals 

HUD 

Office  of  Housing  and  Urban  Development 

IBCA 

Interior  Board  of  Contract  Appeals 

JSS 

Joint  Surveillance  System 

MAR 

Minimally  Attended  Radar 

MCCR 

mission  critical  computer  resource 

MTBF 

Mean  Time  Between  Failures 

MTTR 

Mean  Time  To  Repair 

QA 

Quality  Assurance 

ROCC 

Regional  Operations  Control  Center 

SEI 

Software  Engineering  Institute 

SPO 

Systems  Program  Office 

VACAB 

Veterans  Administration  Contract  Appeals  Board 

WSWA 

Weapon  Systems  Warranty  Act 
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Appendix  II.  Applicability  of  the  Weapon  Systems 
Warranty  Act 

We  read  the  Weapon  Systems  Warranty  Act  (WSWA)  to  have  broad,  though  certainly 
not  universal,  application  to  military  acquisition  programs,  including  those  of  the  Depart¬ 
ment  of  Defense.  WSWA  by  its  terms  applies  to  all  "weapon  systems,*  which  are  de¬ 
fined  broadly  in  the  Act  as  'items  that  can  be  used  directly  by  the  armed  forces  to  carry 
out  combat  missions.*  Radar  systems  for  which  the  DoD  is  responsible,  for  example  — 
even  though  such  systems  might  not  be  thought  of  as  "weapons*  in  common  usage  — 
would  seem  to  fit  within  this  definition  since  they  are  plainly  intended  to  be  used  directly 
by  the  armed  services  in  carrying  out  combat  missions.  The  DFAR  provisions  im¬ 
plementing  WSWA  appear  to  take  such  a  view:  They  specifically  include  'military  sur¬ 
veillance.  command,  control,  and  communication  systems*  within  the  regulatory  defini¬ 
tion  of  "weapon  systems.*  DFAR  Section  246.770-1. 

An  expansive  definition  of  "weapon  systems"  plainly  conforms  to  the  congressional  in¬ 
tent  WSWA  was  enacted  as  a  modification  of  an  earlier  weapon  systems  warranty 
statute,  Section  794  of  Public  Law  98-212,  which  applied  strictly  to  "weapon  systems* 
without  any  explicit  definition  of  that  term.  S.2723,  the  Senate  bill  that  became  WSWA. 
expanded  the  application  of  weapon  systems  warranties  to  weapon  systems  'and  other 
defense  equipment."  The  Senate  Report  accompanying  that  bill  explained  that  this  mod 
ifi cation  was  "intended  to  enlarge  the  types  of  equipment  covered  by  warranties  as  com¬ 
pared  with  Section  794."  S.  Rep.  No.  98-500,  98th  Cong.,  2d  Sess.  243  (1984).  Al¬ 
though  the  added  phrase  "and  other  defense  equipment*  was  eliminated  from  WSWA  in 
conference,  the  Conference  Report  made  dear  that  although  "the  use  of  the  term  other 
defense  equipment’  was  deleted"  from  the  Senate  bid,  the  definition  of  covered  items 
was  not  changed."  H.  Conf.  Rep.  No.  98-1080,  98th  Cong.,  2d  Sess.  323  (1984) 

Thus,  it  would  appear  that  "weapon  system*  should  be  broadly  oonstrued  Consistent 
with  this  view,  AFSC  FAR  Supplement  (C2),  Paragraph  46.770-2.  Policy  (90).  for  ex 
ample,  seems  effectively  to  establish  a  presumption  of  WSWA  applicability  by  requiring 
formal  approval  of  any  determination  that  a  system  Is  not  a  weapon  system. 
("Determination  of  a  Weapon  System.  The  determination  that  an  item  is  not  a  weapon 
system,  as  defined  in  DFARS  46.770-1 .  Definitions,  shall  be  approved  by  toe  Vice  Com 
mender  of  the  Product  Division  for  major  weapon  systems  and  by  the  Director  of  Con¬ 
tracting  for  'other'  systems.  The  approved  determination  shad  be  made  part  of  the  con 
tract  file.") 


Notes 


’’There  are  some  cases  that  at  least  lean  the  other  way,  and  would  appear  to  favor  put¬ 
ting  the  burden  of  proving  an  exclusion  from  warranty  coverage  on  the  contractor.  Eg., 
Westinghouse  Electric  Corp.,  IBCA  No.  182,  60-1  BCA  Paragraph  2550  (1960).  There 
are  still  other  cases  that  seem  unable  to  make  up  their  mind,  and  say  both  (1)  that  the 
government  bears  the  burden  of  proving  that  the  most  likely  cause  of  the  defects  was 
inadequate  contractor  performance,  and  (2)  that  if  the  contractor  contends  that  the 
defects  are  due  to  government  fault,  then  the  contractor  bears  the  burden  of  proving  that 
assertion.  See,  e.g.,  Great  Valley  Construction  Co.,  ASBCA  No.  24449,  81-2  BCA 
Paragraph  15,308  (1981);  George  E.  Jensen  Contractor,  Inc.,  ASBCA  No.  23284,  81-2 
BCA  Paragraph  15,207  (1981).  But  the  prevailing  view  plainly  is  that  the  government 
must  prove  contractor  responsibility  for  the  defect(s).  See  PAR  Section  46.703(c). 

Effective  identification  of  GFE  as  the  cause  of  a  defect,  of  course,  would  in  turn  also 
enable  the  government  to  carry  its  burden  of  proof  in  a  separate  warranty  action  against 
the  supplier  of  the  equipment  to  the  government  under  that  supplier's  warranty,  which 
would  be  independent  of  the  system  warranty. 

^he  basis  for  our  broad  reading  of  WSWA  is  explained  in  Appendix  II,  Applicability  of 
the  Weapon  Systems  Warranty  Act 

4lndeed,  it  is  apparent  that  Congress  intended  WSWA  to  provide  warranty  guidance  for 
procurements  that  might  be  beyond  the  strict  terms  of  the  statute: 

The  omission  of  certain  systems  from  the  statutory  provision,  or  certain  limita¬ 
tions  on  the  warranties  referred  to  in  the  statute,  is  in  no  way  intended  to 
evidence  any  congressional  preference  for  the  warranty  described  in  the 
statute  rather  than  a  more  demanding  warranty.  The  committee  believes  that 
the  statutory  requirement  should  set  forth  a  minimum  standard."  S.  Rep.  No. 
98-500, 98th  Cong.,  2d  Sess.  244  (1984). 

5See  H.  Conf.  Rep.  No.  98-1080,  supra,  323-24  (1984).  Congress  there  condemned  a 
mechanical  approach  to  warranties  as  had  been  pursued  under  WSWA's  predecessor 
warranty  act,  Section  794  of  Public  Law  98-212  (see  Appendix  II). 

"Specifically,  the  Congress  anticipated  that  weapon  systems  warranties  would 
be  negotiated  on  a  case-by-case  basis.  Each  warranty  situation  is  unique. 
Different  approaches  will  be  required  depending  upon  whether  a  system  is  ex¬ 
pendable  (such  as  a  missile)  or  nonexpendable;  what  the  logistical  support  ca¬ 
pabilities  of  both  the  government  and  the  contractor  are;  the  extent  to  which 
the  contractor  has  designed  the  system;  and  numerous  other  factors. 

"It  has  come  to  the  attention  of  the  conferees  that  the  general  approach  of  the 
military  departments  with  regard  to  Section  794  has  been  to  specify  a  warranty 
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clause  and  to  require  that  to  is  be  utilized  with  no  adjustment  in  Its  terms.  The 
warranty  law,  in  the  view  of  toe  conferees,  wai  never  intended  to  create  this 
type  of  simplistic,  mechanistic  approach  to  defense  contracting." 

*DFAR  Section  246.770-3: 

"As  the  objectives  and  circumstances  vary  considerably  among  weapon  sys¬ 
tem  acquisition  programs.  Contracting  Officers  shall  appropriately  tailor  the  re¬ 
quired  warranties  on  a  case  by  case  basis,  todudtog  remedies,  exclusions. 
Imitations  and  duration _ " 

7Koss,  E.  Developing  Reliable  Space  Flight  Software.  Proceeding/:  Annual  Reliability 
and  Maintainability  Symposium,  1 966. 

*S.  Rep.  No.  98-500,  98th  Sees.,  2d  Sees.  244  (1964)  made  dear  that  the  limitation  to 
essential  performance  requirements  was  intended  "to  darify  that  DOD  may  designate 
certain  types  of  performance  characteristics  as  nonessential,  or  as  goals  or  objectives, 
and  remove  such  characteristics  from  the  statutory  requirements." 

•if.  however,  toe  warranty  dause  fails  explicitly  to  provide  that  the  warranty  survives  ac¬ 
ceptance.  then  the  warranty  wW  not  apply  to  patent  defects  dsoovered  after  acceptance. 
See,  Bargen  Expo.  Systams,  Inc.,  IBCA  No.  1346-4-80.  82-2  BCA  Paragraph 
16.0W  (1982);  Instruments  tor  Industry,  Inc.  v.  United  States,  496  F.2d  1157  (2d  Cir. 
1974). 

10See,  e  g.,  S.  Rep.  98-500,  supra  242  (1984).  The  Conference  Report  states: 

THhe  conferees  dscussed  at  lengto  the  concern  that  under ...  toe  language 
in  the  Senate  bifl,  contractors  which  may  have  had  limited  responsibility  in  the 
design  of  a  weapon  system  would  nevertheless  be  caled  upon  to  guarantee 
the  performance  of  that  system.  The  Houee  oonferees  believed  that  perfor¬ 
mance  guarantees  are  appropriate  only  where  a  contractor  had  subetanlai  de¬ 
sign  responsibility.  Though  this  change  In  the  statute  was  not  agreed  upon, 
the  oonferees  dd  agree  that  toe  department  should  have  toe  authority  in  craft¬ 
ing  specific  warranties  to  consider  toe  formulation  of  exclusions  or  limitations 
to  address  situations  where  a  contractor  has  not  designed  a  system,  in  such 
situations,  toe  oonferees  bsMevs  tost  toe  department  oould.  consistent  with  toe 
Intent  of  the  statute,  narrow  toe  scope  of  toe  warranty  if  it  would  be  inequitable 
to  require  a  warranty  of  al  essential  performance  requirements  because  of  a 
lack  of  contractor  design  involvement'  H.  Conf.  Rep.  No  98-1080.  supra 
324. 

DFAR  Section  246.770-3  similarly  provides,  among  other  things,  that  contracting  officers 
"may  narrow  toe  scope  of  a  warranty  where  such  a  appropriate  (e  g  .  where  it  would  be 
inequitable  to  require  a  warranty  of  all  essential  performance  requirements  because  a 
contractor  had  not  designed  toe  system)." 


11  On  the  other  hand.  Congress  plainly  is  of  the  view  that  the  government  could  not 
properly  require  a  design  change  that  made  compliance  with  essential  performance  re¬ 
quirements  impossible  without  adjusting  the  warranted  performance  requirements. 
Thus,  the  Conference  Report  accompanying  WSWA  provides: 

THhere  is  some  concern  about  the  appropriate  manner  of  dealing  with  con¬ 
tractual  changes  after  contract  execution.  It  is  the  understanding  of  the  con¬ 
ferees  that  If  the  United  States  takes  any  actions  which  affect  the  contractor’s 
ability  to  comply  with  the  terms  and  conditions  of  the  contract,  the  contractor  is 
entitled  to  an  equitable  adjustment  of  such  terms  and  conditions  to  account  for 
such  act.  For  example,  if  the  government  would  direct  a  change  that  affected 
the  performance  of  a  system,  the  conferees  believe  it  would  be  necessary  for 
the  government  to  grant  an  equitable  adjustment  to  the  extent  appropriate  in 
the  terms  of  any  performance  guarantee  in  the  contract  to  recognize  the  effect 
of  such  change." 

H.  Conf.  Rep.  No.  98-1080,  supra,  at  324.  The  negative  implication  of  this  congressional 
instruction,  of  course,  is  that  design  changes  that  do  not  affect  essential  system  perfor¬ 
mance  do  not  invalidate  performance  warranty. 

12The  statute  provides  authority  for  warranting  all  systems  in  such  circumstances.  10 
U.S  C.  Section  2403(f)  ("nothing  in  this  section  prohibits  the  head  of  the  agency  con¬ 
cerned  from  negotiating  a  guarantee  [of  essential  performance  requirements]  for  a 
weapon  system  not  yet  in  mature  fud-scale  production"). 

13FAR  Section  46.705(b)  &  (c)  provide  as  follows: 

"(b)  Warranty  clauses  shall  not  limit  the  Government's  rights  under  an  inspec¬ 
tion  clause  ...  in  relation  to  latent  defects,  fraud,  or  gross  mistakes  that 
amount  to  fraud. 

"(c)  Except  for  warranty  clauses  In  construction  contracts,  warranty  clauses 
shall  provide  that  the  warranty  applies  notwithstanding  inspection  and  accep¬ 
tance  or  other  clauses  or  terms  of  the  contract." 

14While  some  commentators  apparently  find  the  basis  for  the  E.2.(c)  remedy  under 
WSWA  to  be  "vague  and  unclear,'  see  "Weapon  Systems  Warranties  —  Basic  Prin¬ 
ciples  and  Guidelines,"  The  Government  Contractor  Briefing  Papers,  No.  85-7  (July 
1985),  the  addHtonal  remedy  Is  plainly  authorized  under  10  U.S.C.  Section  2403(g)(5), 
which  authorizes  procuring  agencies  to  include  in  their  contracts  "guarantees  that  pro¬ 
vide  more  comprehensive  remedies  than  the  remedies  specified"  in  the  statute. 

,#As  a  practical  matter,  where  system  performance  Is  warranted  contractors  may  insist 
on  performing  all  maintenance  on  warranted  systems  during  the  life  of  the  warranty  to 
guvd  against  warranty  kabMty  triggered  by  Improper  maintenance.  This  is  especially 
the  case  where  software  is  warranted,  since  "maintenance'  in  the  oontext  of  software 
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means  not  only  preservation,  but  enhancement  or  improvement  Contractors  simply 
may  be  unwilling  to  warrant  software  performance  in  all  circumstances  unless  they  can 
control  all  software  maintenance  during  the  warranty  period. 


While  Congress  was  plainly  concerned  about  tying  maintenance  agreements  to  perfor¬ 
mance  warranties  under  WSWA  in  view  of  the  general  policy  favoring  broad  competition, 
see.  e.g.,  S.  Rep.  No.  98-500,  tupra,  242,  we  do  not  believe  that  the  Competition  in 
Contracting  Act,  P.L.  98-367,  98  Stat.  1175,  or  any  other  provision  of  law  precludes  in¬ 
cluding  in  system  procurements  provisions  for  the  prime  contractor  to  perform  all  re¬ 
quired  maintenance  during  the  term  of  the  warranty,  so  long  as  the  system  procurement 
itself  complied  with  all  competitive  procurement  requirements.  Such  clauses  should  be 
carefully  considered  and  drafted,  however,  because  the  maintenance  provisions  will  like¬ 
ly  increase  the  cost  of  the  contract  (though  that  cost  may  be  offset  by  a  decreased  war¬ 
ranty  cost).  Tt<e  government  should  make  sure  that  it  is  not,  in  effect,  paying  twice  for 
the  same  protection  (warranty  and  maintenance). 
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